Microservices Communication — Queues Topics and Streams
Tags: microservices, aws, beginners, cloud
Published: 2022-12-11 11:46:36

In this article, I will speak about types of messages broker that are famous in microservices communication.

Brokers are often used as middleware to manage communication between microservices. It’s a great choice for asynchronous communication.

For example… Ops… wait


### Context
Here we have an example of delivery service. In a normal logistical system, we need to receive an order and delivery them. To deliver an order is needed to create a route with a pickup point and delivery point. Ok… now, let’s go to an example:

Rather than the order service sending an order information to the route service directly, and the route service sending an route to the driver service,


![synchronous communication](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/r2s3jh9g1c5fl9m7hi3v.png)

the order service sends data to the broker and it sends the information to the route service.


![Asynchronous communication](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iwksk2x8ometvwl98yyy.png)


This communication style is very famous in a microservices architecture.

Exist many brokers tend to provide queues, topics and streams

### QUEUES
Queues are typically communication point to point. A service that could be called a sender or provider sends a message to a queue and another service that is normally called consumer reads from that queue.


![Service A sends a message to the broker and service B consumes the message by the broker
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pwutqhv4fx3a0nx6gqtn.png)


If you want to see this example in practice check this other story: Microservice Communication — AWS SQS | Sending Messages

### TOPICS
Topics communicate from one sender/provider to one or many consumers These consumers need to be able to subscribe to the topic. And, each consumer that got a subscription to the same topic receives a copy of the message that was sent.

In the practice, a consumer could be a microservices.



![Service A sends a message to the broker and another service consuming the same message by the broker](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6s3rz1zzjjo73cwfh3zb.png)


### STREAMS
Streams data communicate to consumers, sending data records simultaneously by a lot of data sources. The data source could be, mobile apps, microservices, and IoT resources, and you can have a large data in real-time. Some scenario to use that broker type is:

a social media feed
in-game to store players' activity
logs transactions


![Producers sending a large of data streams in real-time data are stored and sent to many consumers](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wokagtnobf5dhjtkrbw6.png)


### Conclusion
Motivation to use a broker:

Guaranteed delivery: With a broker, there is guaranteed delivery, if any service keeps up unavailable for any time, the message that should be sent to the unavailable service, will keep stored in the broker until the service is back to get available again.

Scalability: There is a horizontal scale for services. If you use k8s for example, There is a unique service scaled with many pods; the service is a consumer and the pods are the workers, so there is have a consumer by from a queue or topic with any worker and you don’t have repeated data.

Order guaranteed between messages — FIFO: Most brokers has this feature that guarantees order between the message as AWS SQS.

Reprocess Messages: Brokers have a mechanism to reprocess messages that for any reason can’t be processed. A consumer tries to receive a message and happens an error, and your retry time reaches a limit, you can attach a dead letter, and automatically this message that could be lost, is sent to DLQ (dead latter queue).


### References

> [Building Microservices : Designing Fine-Grained Systems](https://amzn.to/3zFxgVQ)
> [Kafka: The Definitive Guide: Real-Time Data and Stream Processing at Scale](https://amzn.to/3ngF1u5)