Fundamentals of System Design Chapter 10: Message Queues

Introduction

Real World Problem

Imagine a popular restaurant with lots of customers at it’s busiest hour. All the customers want to get meals the moment they walk in. It could be chaotic if the restaurant does not have a system in place to manage the orders. This means mistakes might be made in the kitchen and some orders might be missed. As a customer you wouldn’t want to see someone get their meal before you and you came in before them right? An ordering system is therefore needed to make the service organized.

Solution

To manage the flow of the customers, the restaurant introduces a kitchen order queue. A waiter takes a customer’s order and writes on a ticket. The waiter then places the ticket on the counter which is designated for incoming orders. The order queue lines up the orders according to the sequence they were placed. The chefs will prioritize the meals starting with the oldest orders, i.e first come first serve. If the kitchen is busy the orders will continue to pile up and the staff will work on them whenever they are ready. The restaurant introducing an ordering queue, they can now easily manage the flow of the customers. The chefs can focus on completing one order at a time and also the customers will get their meals in a fair manner, no order will be unfairly delayed.

What’s a Message Queue?

Normally in the client-server model, the client sends a request, the server receives it, does some work and then responds. But what if the server has to call multiple services or perform tasks that are long-running? You have to allow the client to continue doing some other work as they are waiting for a response. That’s where message queues come in place. Message queues is an asynchronously communication protocal used in distributed systems or in service to service communication. It allows applications/services to exchange messages by making use of queues. The sender places the message in a queue, and the receiver works on the message and responds whenever it’s ready.

How does a message queue work?

1. Producer sends a message - The producer application is the creator of a message. It sends the message to a message broker.
2. Broker places the message in a queue - A broker manages queues and facilitates communication between the producer and consumers. The message broker accepts the message and stores it in a message queue. A queue is the storage area where messages are held before getting consumed.
3. Consumer Subscribes(Pull Messages) - The consumer applications pulls the message from the message queue using polling as soon it’s received.
4. Message processing - The consumer processes the received message.
5. Acknowledgment(Success) - Once the message has been processed the consumer sends an acknowledgment back to the broker to confirm the message was received and successfully processed. In some systems such as RabbitMQ, the message can be re queued if the message isn’t acknowledged.
6. Message Deletion - The message is then removed after an acknowledgment to avoid it from being processed again.
7. Dead-letter Queue(DLD) - If the message fails to be processed after a number of retries, It’s moved to a dead-letter queue. This allows processing failed messages without clogging the main queue.

Types of message queues

There are different types of message queues, each designed to solve different problems:

1. Point-to-Point(P2P) Queue

In this model messages are sent from one producer to one consumer. It’s a model where a message needs to processed by a single consumer for instance in task distributions where only one worker need to handle a task.

2. Publish-Subscribe(Pub/Sub) Model

Messages are published to a topic and multiple consumers can subscribe to that topic and receive messages. A popular use case is broadcasting events to multiple services such as notifications.

3. Priority Queue

Messages in the queue are assigned a tag(priority), higher priority messages are processed before lower-priority ones. Best use case is when some tasks need to be handled more urgently than others.

Benefits of message queues

Message queues offers a number of benefits such as:

1. Simplified Decoupling

A decoupled architecture is where different components that makes up a system interact with each other using well defined interfaces rather than depending tightly on each other. By using queues between components you can decouple the dependencies. This enables different parts of a system to evolve independently.

2. Asynchronous Communication

Message queues enables asynchronous communication between different parts of a system. Queues enables consumers to process long running tasks in the background, leading to an improved system performance.

3. Scalability and Load Balancing

Queues can handle increased loads as it can employ multiple consumers to process the messages concurrently. Queues can scale horizontally to match increased system demands without overwhelming the system.

4. Reliability and Fault Tolerance

Messages are stored in a queue until they are acknowledged. This ensures a reliable delivery even in the event of system or network failures.

5. Buffering Message queues acts like a buffer between components. If the producers is generating messages faster than a consumer can process, the queue temporarily holds the messages until the consumer is ready to handle them.

6. Persistence Every systems will always fail at some point. It could be caused by bugs, errors, network failures etc. If your data is not persisted then it’s gone forever. MQ’s provides data persistence and it mitigates this by persisting data until it has been fully processed.

7. Ordering Guarantee An ordering guarantee is provided by an MQ as it uses the First In First Out Model(FIFO). The earlier enqued message will be delivered sooner.

When to use message queues

Message queues are asynchronous in nature. They are not for real time communication; you can’t use them when you want an immediate response. The following are ideal scenarios of when to use message queues:

1. Long-running processes and background jobs When a request takes a significant amount of time to be processed, then you need to make use of message queues. An MQ enables the tasks to be processed in the background, avoiding blocking the main application flow. Some real world examples include:

• Image scaling
• Calculations
• PDF processing
• Video encoding
• Sending batch emails/notifications

2. The middleman between services Message queues are ideal for communication and integration between services. MQs avoid system failures, when one system is unavailable, due to outages or overloading, the message will still be received as it will be persisted in the queue until it’s ready to be consumed. MQs provides a means for loosely coupled, independent systems to communicate reliably and asynchronously. Decoupling processes, improves system reliability and scalability.

3. Ordering and Consistency In some systems for instance in the banking software, the order of operations is critical e.g updating the user balance after a transaction. This ensures data consistency. If the balance is not updated properly, the user may spend more than they have leading to overdraft, failed transactions or reconciliation issues.

Popular Message Queues

The following are message queues that are popular in the industry for specific use cases.

1. Rabbit MQ

This is a free and open source platform used as a streaming and messaging broker.

2. Kafka

Linkedn Open sourced Kafka in 2011 which is an event streaming platform. Kafka is optimized for writes, It offers a high-throughput, low-latency platform for handling real-time data feeds.

3. IBM MQ

IBM MQ is very popular in the financial world. You however need a license to use it in production.

Conclusion

When you have a system receiving more data than it can process, we can persist the data temporarily before it’s processed. This model which is known as asynchronous messaging prevents data loss and enables the system to continue functioning even when the processes fails.

Thank You!

I’d love to keep in touch! Feel free to follow me on Twitter at @codewithfed. If you enjoyed this article please consider sponsoring this blog for more. Your feedback is welcome anytime. Thanks again!