This is a series of articles dedicated to the optimal choice between different systems on a real project or an architectural interview.

At work or at a System Design interview, you often have to choose the best message broker. I plunged into this issue and will tell you what and why. What is better in each case, what are the advantages and disadvantages of these systems, and which one to choose, I will show with several examples.

Main differences between Kafka, RabbitMQ, and SQS:

Architecture:

Kafka is a distributed, publish-subscribe messaging system that uses a messaging queue as a durable store.
RabbitMQ is a message broker that implements the Advanced Message Queuing Protocol (AMQP) and supports a wide range of messaging patterns.
SQS is a managed message queue service that provides a simple and scalable way to transmit messages between applications.

Message Processing:

Kafka is designed for high-throughput, real-time data streaming and batch processing. It supports parallel processing of messages using partitions.
RabbitMQ supports a wide range of messaging patterns, including publish-subscribe, point-to-point, request-reply, and fan-out. It is also capable of parallel processing of messages using queues.
SQS is designed for simple, asynchronous messaging between applications, with a focus on ease of use and scalability. It provides a reliable and highly available message queue service, but it does not support real-time data streaming or parallel processing.

Durability:

Kafka provides a high level of durability for messages by storing them on disk and replicating them across multiple nodes in a cluster.
RabbitMQ provides durability for messages by storing them on disk and keeping backups of messages on other nodes in a cluster.
SQS provides a high level of durability for messages by automatically storing them redundantly across multiple Availability Zones in the same region.

Scalability:

Kafka is highly scalable and can handle high volumes of messages. It can be horizontally scaled by adding more nodes to the cluster.
RabbitMQ is also scalable, and it can be horizontally scaled by adding more nodes to the cluster.
SQS is a fully managed service that is highly scalable, and it can automatically scale to handle the number of messages being sent and received.

Throughput:

Kafka has been benchmarked to handle millions of events per second.
RabbitMQ has a more modest throughput, typically handling tens of thousands of events per second.
The exact throughput of SQS will depend on the number of messages being sent and received and the size of the messages, but it is generally able to handle thousands of requests per second.

Latency:

Kafka is optimized for low latency, with message delivery times typically in the range of a few milliseconds.
RabbitMQ has higher latency compared to Kafka, with message delivery times typically in the range of a few tens of milliseconds.
The latency of SQS will depend on the number of messages being sent and received and the size of the messages, but it is generally able to deliver messages within a few seconds.

Cost:

Kafka can be run on-premises or in the cloud, and the cost will depend on the hardware and infrastructure required to run the system.
RabbitMQ can also be run on-premises or in the cloud, and the cost will depend on the hardware and infrastructure required to run the system.
SQS is a fully managed service provided by Amazon Web Services (AWS), and the cost will depend on the number of requests made and the amount of data transferred.

Complexity:

Kafka can be complex to set up and manage, especially at scale.
RabbitMQ is less complex than Kafka, but still requires a certain level of technical expertise to set up and manage.
SQS is a fully managed service, so it requires no setup or management, making it the simplest of the three systems to use.

In conclusion, the differences in numbers between Kafka, RabbitMQ, and SQS will depend on the specific requirements of your application and use case. If you require high-throughput, low-latency messaging, then Kafka may be the best choice. If you need a more modest, versatile system that supports different messaging patterns, then RabbitMQ may be a good choice. If you require a simple, scalable, and fully managed message queue service in the cloud, then SQS may be the best choice.

3 examples in which cases it is optimal to use these 3 message brokers

Apache Kafka

Imagine you're building a recommendation system for an e-commerce website. The recommendation system needs to process a large amount of data in real-time, such as user behavior data (e.g., clicks, purchases, searches), product data (e.g., descriptions, prices, images), and inventory data. To process this data, you could build a data pipeline with the following components:

Data producers: Multiple systems that generate the user behavior, product, and inventory data in real-time.
Apache Kafka: The central hub for all the data in the pipeline. The data producers would publish the data to Kafka topics, and the other components in the pipeline would subscribe to these topics to consume the data.
Data processing: A set of Apache Kafka Streams applications that would process the data as it arrives in real-time. These applications could perform tasks such as:

Enriching the user behavior data with product and inventory information.
Aggregating the data to compute metrics such as the number of clicks per product or the number of purchases per user.
Transforming the data into a format suitable for recommendation algorithms.

Recommendation algorithms: A set of algorithms that would use the processed data to generate recommendations for users.
Data storage: A database or data lake where the processed data would be stored for later use.

By using Apache Kafka as the central hub in this pipeline, you would benefit from its high-throughput, low-latency, and fault-tolerant properties. Additionally, you could scale the pipeline horizontally by adding more data producers, data processors, or recommendation algorithms as needed, and you could also easily add or modify the processing steps in the pipeline without disrupting the overall system.

RabbitMQ

Imagine you're building a system to process online orders for a large e-commerce website. The system needs to handle a high volume of orders and perform several tasks for each order, such as checking inventory, calculating taxes and shipping costs, and sending emails to the customer. To process the orders, you could build a system with the following components:

Order management system: A system that generates the orders and sends them to RabbitMQ for processing.
RabbitMQ: The message broker that would manage the tasks for each order. Each order would be represented as a message, and RabbitMQ would route the messages to the appropriate consumers for processing.
Inventory management system: A system that would check the inventory for each order and send a response back to RabbitMQ indicating whether the order can be fulfilled.
Tax calculation system: A system that would calculate the taxes and shipping costs for each order and send a response back to RabbitMQ with the calculated amount.
Email system: A system that would send an email to the customer with the order details and a receipt after the order is processed.

By using RabbitMQ in this system, you would benefit from its ability to manage the tasks for each order as separate messages and route them to the appropriate consumers. Additionally, RabbitMQ provides robust mechanisms for handling errors and retrying tasks, so you can ensure that each order is processed correctly even if there are errors or failures in the underlying systems. Additionally, RabbitMQ provides features such as message acknowledgment and dead-letter exchanges, which can help ensure that messages are processed only once and that errors are handled appropriately. Furthermore, RabbitMQ supports different messaging patterns, such as publish-subscribe and request-reply, which would allow you to build a flexible and scalable system to handle the processing of online orders.

Amazon SQS

Imagine you're building a system to process images for a large online photo-sharing website. The system needs to handle a large volume of images and perform several tasks for each image, such as resizing, adding filters, and uploading to a cloud storage service. To process the images, you could build a system with the following components:

Image upload system: A system that allows users to upload images to the website and sends the images to Amazon SQS for processing.
Amazon SQS: The message broker that would manage the tasks for each image. Each image would be represented as a message, and SQS would store the messages in a queue until they can be processed.
Image processing system: A set of EC2 instances that would retrieve messages from SQS, process the images, and send the processed images to a cloud storage service.
Cloud storage service: A service such as Amazon S3 or Amazon EBS, where the processed images would be stored for later use.

By using Amazon SQS in this system, you would benefit from its scalability and reliability. SQS can handle millions of messages per second, so you can easily scale the image processing system by adding more EC2 instances as needed. Additionally, SQS provides robust mechanisms for handling errors and retrying tasks, so you can ensure that each image is processed correctly even if there are errors or failures in the underlying systems. Additionally, SQS provides features such as message visibility timeout and message deduplication, which can help ensure that messages are processed only once and that errors are handled appropriately. Furthermore, SQS is a managed service, so you don't have to worry about managing the underlying infrastructure, which would allow you to focus on building the image processing system.

Message broker selection cheat sheet: Kafka vs RabbitMQ vs Amazon SQS

zproxy.org