Asynchronous messaging patterns for Microservices

“If your application is cloud-native, or large scale, or distributed and doesn’t include a messaging component, that’s probably a bug”

Tim Bray

General purpose internet software geek

How Asynchronous messaging helps in software architecture
When it comes to software architecture, there are 2 things very important

1. Divide and Conquer: With Microservices we already apply Divide and Conquer

2. Loose coupling: And through Asynchronous messaging we can achieve Loose coupling

Synchronous messaging

1. Synchronous systems are tightly coupled
2. Problems in downstream dependencies can have immediate impact on upstream callers, and that’s why we have Circuit breaker pattern
3. Retry from upstream callers can all-too easily fan-out and amplify problems

Hence here comes the line …

“… and some things simply take too much time to wait, or are asynchronous by nature”

Application integration patterns

Message exchange

One way

1. There’s a sender and a receiver
2. Message channel in between can decouple both sides, so either know nothing about each other
3. No response or acknowledgement received Request-response
4. There’s a sender and a receiver
5. 2 dedicated message channels for request and response
6. Returns address and correlation ID

obvious questions
Question: How requester know where to send the response?
Answer: Return Address pattern, requester adds meta information to the request message that instructs the responder about the address of the return channel

Question: How requester know how to assign an incoming response to a previous request?
Answer: Return Address pattern, requester adds meta information to the request message with a unique ID for the request. the responder is asked to forward that Id also into the response message

Message channel

Point to point

1. Implemented by Queues
2. Sender to send messages into the queues, there can be multiple senders
3. And there can be one to many receivers to consume messages out of the queue
4. Queue acts as a load balancer in front of the receiver, which means every message from the queue is delivered to one of the receivers
5. Benefits a. Easy to scale out receivers if load on the queue increasing b. Queue can persist messages c. Messages do not need to be consumed right away, queue can flatten a peak load for receiver, so queue can be called a buffering load balancer in front of the receiver d. We can also safely take receiver processes offline for maintenance work, and no danger of losing messages as they are buffered in queue

Publish-subscribe model

1. One or more publisher
2. Every subscriber will receive every message
3. Topic is not persisted, so if any subscriber is offline, they will lose messages
4. If we add another subscriber it doesn’t help with the load as all the subscribers will receive every message

AWS

1. SQS for queue
2. SNS for topic
3. Bot hare serverless, no infra to manage
4. Consume functionality through simple API
5. Both can be event source for AWS lambda
6. If we need strict order for our messages both (SNS, SQS) also support FIFO message ordering.

Amazon MQ

1. If we are restricted messaging protocol like JMS or AMQP, there’s Amazon MQ
2. Non serverless
3. Managed a. Apache Active MQ b. RabbitMQ

How to scale out for Pub-sub?

Topic Queue chaining (Topic+Queue)

1. Publisher at left
2. Sends messages to topic
3. Now we do not directly attach our consumer processes to the topic, but we put queue in between
4. Then we have our consumer processes
5. Benefits a. We can have fan-out functionality, b. and have consumer scale out at the same time c. edit resiliency as messages will be buffered so consumers can go offline for maintenance work

Message Routing Patterns
Message Filter

1. possible that subscribers are interested for a sub set of messages, for example in above case 1 subscriber is only interested in orange messages
2. dedicated topic (channel) can be added for each message types, but if there’s multiple permutations it can be tough to manage
3. so here, each subscriber can individually agree with the messaging system that it is only interested in a certain set of messages. And it is done by the meta information of those messages
4. Publisher stays totally unaware of these

Recipient list

1. Same as Message Filter
2. Recipient list is added which manages the messaging route
3. Its our own code, can be put in Publisher
4. Maintain the code by yourself

Scatter-Gather pattern

1. For use cases where you need to distribute requests across potentially relevant or interested parties, and need to capture individual responses
2. Use-cases – parallel processing
3. Process a. Requests are sent to potential responders b. Responders work on their individual response c. And send it back to response queue d. Return address pattern is leveraged so responders know address of the response queue e. From there individual responses are consumed b an aggregator component f. Finally processed by a processor component g. Aggregator and processor can be separate processes or same process h. Requester can be in same application as aggregator and processor