RabbitMQ

I've had good experiences moving from Supervisord to using systemd for managing processes, especially for setups involving RabbitMQ and Symfony. Systemd not only integrates well with the system, offering better control and management, but it also simplifies logging through journalctl and handles automatic restarts seamlessly.

Here's what I did to make the switch: - Craft a Service File: I wrote a .service file in /etc/systemd/system/ to describe my service. It includes details on how to start and stop the process, among other things. - Set Up Service Behavior: Inside this file, I specified commands like ExecStart for launching my process, Restart to ensure it always restarts after failure, and set the User to define which user runs the process. - Enable and Launch the Service: With systemctl enable my-service.service, I made sure my service would start on boot, and systemctl start my-service.service got it running right away. - Manage and Log: Whenever I needed to check on things, journalctl was there for logs, and systemctl helped me manage the service (like checking its status or restarting it). - Switching to systemd resolved the disconnection issues I faced without needing any workarounds like restartingI've had good experiences moving from Supervisord to using systemd for managing processes, especially for setups involving RabbitMQ and Symfony. Systemd not only integrates well with the system, offering better control and management, but it also simplifies logging through journalctl and handles automatic restarts seamlessly.

Here's what I did to make the switch: - Craft a Service File: I wrote a .service file in /etc/systemd/system/ to describe my service. It includes details on how to start and stop the process, among other things. - Set Up Service Behavior: Inside this file, I specified commands like ExecStart for launching my process, Restart to ensure it always restarts after failure, and set the User to define which user runs the process. - Enable and Launch the Service: With systemctl enable my-service.service, I made sure my service would start on boot, and systemctl start my-service.service got it running right away. - Manage and Log: Whenever I needed to check on things, journalctl was there for logs, and systemctl helped me manage the service (like checking its status or restarting it). - Switching to systemd resolved the disconnection issues I faced without needing any workarounds like restart jobs. It felt like a cleaner, more reliable approach.

I think you may be mixing concerns a bit. Also, the authentication mechanisms for various tools may not necessarily play well with another, and/or you may need different intra-service auth vs. public-facing/customer sessions/tokens. If you need to have disparate tools authenticate to one another with a bearer-type token mechanism, consider Vault. It has excellent support for at least one of the tools you mention (RabbitMQ.)

For flexible token auth, JWTs.

We have faced the same question some time ago. Before I begin, DO NOT use Redis as a message broker. It is fast and easy to set up in the beginning but it does not scale. It is not made to be reliable in scale and that is mentioned in the official docs. This analysis of our problems with Redis may help you.

We have used Kafka and RabbitMQ both in scale. We concluded that RabbitMQ is a really good general purpose message broker (for our case) and Kafka is really fast but limited in features. That’s the trade off that we understood from using it. In-fact I blogged about the trade offs between Kafka and RabbitMQ to document it. I hope it helps you in choosing the best pub-sub layer for your use case.

It depends on your requirements like number of messages to be processed per second, real time messages vs delayed, number of servers available for your cluster, whether you need streaming, etc.. Kafka works for most use cases. Not related to answer but would like to add no matter whatever broker you chose, for connecting to the broker always go for the library provided by the broker rather than Spring kafka or Spring AMQP. If you use Spring, then you will be stuck with specific Spring versions. In case you find bugs in spring then difficult because you will have to upgrade entire application to use a later Spring core version. In general, use as minimum libraries as possible to get rid of nuisance of upgrading them when they are outdated or bugs are found with them.

Hello, i highly recommend Apache Kafka, to me it's the best. You can deploy it in cluster mode inside K8S, thus you can have a Highly available system (also auto scalable).

Good luck

For large amounts of small tasks and caches I have had good luck with Redis and RQ. I have not personally used celery but I am fairly sure it would scale well, and I have not used RabbitMQ for anything besides communication between services. If you prefer python my suggestions should feel comfortable.

Sorry I do not have a more information

ZeroMQ is fast but you need to build build reliability yourself. There are a number of patterns described in the zeromq guide. I have used RabbitMQ before which gives lot of functionality out of the box, you can probably use the worker queues example from the tutorial, it can also persists messages in the queue.

I haven't used Amazon SQS before. Another tool you could use is Kafka.

Both would do the trick, but there are some nuances. We work with both.

From the sound of it, your main focus is "not losing messages". In that case, I would go with RabbitMQ with a high availability policy (ha-mode=all) and a main/retry/error queue pattern.

Push messages to an exchange, which sends them to the main queue. If an error occurs, push the errored out message to the retry exchange, which forwards it to the retry queue. Give the retry queue a x-message-ttl and set the main exchange as a dead-letter-exchange. If your message has been retried several times, push it to the error exchange, where the message can remain until someone has time to look at it.

This is a very useful and resilient pattern that allows you to never lose messages. With the high availability policy, you make sure that if one of your rabbitmq nodes dies, another can take over and messages are already mirrored to it.

This is not really possible with SQS, because SQS is a lot more focused on throughput and scaling. Combined with SNS it can do interesting things like deduplication of messages and such. That said, one thing core to its design is that messages have a maximum retention time. The idea is that a message that has stayed in an SQS queue for a while serves no more purpose after a while, so it gets removed - so as to not block up any listener resources for a long time. You can also set up a DLQ here, but these similarly do not hold onto messages forever. Since you seem to depend on messages surviving at all cost, I would suggest that the scaling/throughput benefit of SQS does not outweigh the difference in approach to messages there.

If you want to get deep insights and fast issue resolution have a look at INSTANA.

There is a public sandbox to get first insights and feeling for the tool. If you like it you can also run a free trial if you like.