Queue-based Architecture (Arc101)

Today, I would talk about the queue-based architecture. First of all, why/where we should have the queue-based architecture?

If you are using RESTful architecture and the service goes down temporarily, the API will be blocked and all cycle will be disabled.

Your API will wait until the response comes back. If the error is returned your journey will be all stopped if there is any component goes failed in the single journey.

In a queue-based architecture, the message will be added in the queues between services, if there is any service down, the queue will grow until it’s recovered. After it is recovered, the consumer service will take the queued message again. (If it’s short downtime, the user will not be able to recognise it)

In queue-based architecture there are few role players.

• Message: message has the header and body. (This will be similar context with the RESTful API header and body)
• Queue: The queue holds the messages between producer and consumer.
• Producer: service that produces a message
• Consumer: service the consumes a message.
• Message broker: gather, route, and distribute messages.