Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
The community reviewed whether to reopen this question last month and left it closed:
Original close reason(s) were not resolved
Improve this question
As a product scales, APIs and two tier architecture incurs bottlenecks, data contention, downtime. Messages can become lost, if there are thousands or millions of requests & activity
What makes websocket connections beneficial vs Kafka? What are the best use cases for each?
Is there an example such as a large scale chat application where a hybrid of both technologies are necessary?
Websockets should be used when you need real-time interactions, such as propagating the same message to multiple users (group messaging) in a chat app.
Kafka should be used as a backbone communication layer between components of a system. It fits really well in event-driven architectures (microservices).
I see them as 2 different technologies which have been developed for 2 different purposes.
Kafka, for example, allows you to reply messages easily, because they are stored on the local disk (for the configured topic retention time). Websockets are based on TCP connections (two-way communication), so they have a different use-case spectrum.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
I'm doing a message publisher and a receiver to/from rabbitmq queue.
I'm planning to use one rabbitmq channel for publishing messages and one for fetching, but i also want my code to be asynchronous, is it the right way to use one rabbitmq channel per multiple goroutines?
I'm not a golang-guy, by I use every day RabbitMq with .Net driver; .Net driver channels (an abstraction that encapsulate interactions with queue/exchange and message publishing/subscribing) are very similar to golang RabbitMq channels, so I think my answer can help you.
While connections are tread safe by design and are supposed to be shared between threads, channels are not: so, if different aysnchronous goroutines can be run in different threads (this is up to you: I don't known how golang runtime works) you should not share the same channel instance between them.
I hope this can help you.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
" 2018: The Year of Service Mesh "
Recently, I did some research on the service Mesh for handling service-to-service communication, and the implementations created in the last two years. But I'm still so confused about the real differences between Istio and Conduit that already give the same features.
So it is obvious that they are competitors but, based on what, we can choose, as clients, the project that we should take?
Both technologies provide service mesh communication, and developed with plugin architecture, the list includes Prometheus,Zipkin etc.
As far as features are concerned, they will be at feature parity if not now, but at some point in the future. Especially with Kubernetes etc, you can always replace one with other without affecting your services much.
I would go with Istio if your services are based on Kubernetes as both are backed by Google, and expect them to work much better compared to Conduit going forward.
Last I read Istio will be supported on Docker Swarm as well, so it all depends where you are running your services and which mesh framework is most suited for it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm using phoenix controllers to receive data via REST calls. So an iOS app could send the "events" for each user and based on the event, I need to calculate the score/points and send it back to the user. Calculation and sending back to the user can happen asynchronously. I'm using Firebase to communicate back to the user.
What is a good pattern to do calculation? Calculate could be bunch of database queries to determine the score of that event. Where should this calculation happen? Background workers, GenEvent, streams within user-specific GenServer (I have supervised GenServer per user).
I would look at Phoenix channels, tasks and GenServer.
Additionally, if you would like to manage a pool of GenServer workers to do the calculations and maybe send back the results for you, check out Conqueuer. I wrote this library and it is in use in production systems for my company. It is uses poolboy, which is probably the most pervasive pool management library in Erlang/Elixir.
Admittedly, I do not fully understand the requirements of your system, but it does not seem to me GenEvent has a place in your requirements. GenEvent is about distributing events to one or more consumers of events. So unless you have a graph of processes that need to subscribe to events being emitted from other parts of your system I do not see a role for it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Is it a good idea to use a message queue as websocket server in production (instead of Java EE #ServerEndpoint)?
It would establish a loose coupling towards the JS client and perhaps reduce the load from the application, but are there major disadvantages? Should one really expose a MQ over the web?
One can send messages to websocket clients from within a java web application without the help of a message queue. And this is a good enough solution as long as you do not need the additional features that message queues have to offer (QoS 1/2, Retained messages, Last Will and Testament, ... for some more benefits of using a mq see for example: http://www.hivemq.com/mqtt-over-websockets-with-hivemq/)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
How a Queue and Topic can be applied in airport management when a plane arrives?
At the airport there are many systems that interact with the plane at ramp time. These include fueling and servicing the plane, gate management, passenger announcements, FAA filings, and 3rd party vendors such as those who SMS you with updates. All of these are different families of applications both within and external to the airport's network fabric.
Publishing a single event notification on a topic is a good way to update all interested systems at once. Rather than establishing dozens of point-to-point interfaces for all these systems, they are all allowed to subscribe to the topic of interest. The publications can be converted to queued delivery on a per-receiver basis for legacy apps or external apps that cannot issue a subscribe command.