Message-broker vs Rest API

Recently, a developer raised his hand and asked why we needed to add a message broker to the application we are building, can’t we just use normal Rest API? I used to ask myself the very same question in the old days. I would say the theory explanation is not sufficient to understand the underlying concept, you have to face the situation where the answer is message broker.

A message broker offers the advantage of enabling your systems to operate independently at various times without disrupting the entire ecosystem. For instance, you can introduce a new product even if the marketplace is temporarily unavailable, assuming that the marketplace is set up to subscribe to updates about new products.

However, it’s worth noting that you can adopt a hybrid approach. There’s no issue with, for example, offering APIs for inquiries while executing actions or commands through a queued messaging system. This can function well as long as your system can gracefully handle situations where the API may be unavailable, like when it can’t retrieve the current courier availability for a specific area.

When Should You Use Message-broker?

Consider an e-commerce website (like Amazon) where users can place orders that need to be processed.Consider an e-commerce website (like Amazon) where users can place orders that need to be processed.

The order processing system might involve several steps, such as inventory checks, payment processing, shipping, and so on, each of which can potentially take some time and are ideally handled asynchronously.

1. Inventory Checks : When a user places an order, the system should check whether the ordered products are in stock. You can send a message to a queue that is consumed by a service responsible for checking inventory. This way, even if the inventory service is temporarily down or overloaded, the order messages won’t be lost — they’ll be processed as soon as the service is available.
2. Payment Processing : The payment processing might be done by another microservice. Once the inventory check is completed, a message can be sent to a queue for the payment service. This decouples the payment processing from the inventory checking, allowing these operations to scale independently.
3. Shipping : After payment confirmation, a message can be sent to another queue that’s responsible for handling shipping. Again, this service might take some time, but because it’s decoupled from the rest of the system, it won’t slow down other operations.
4. Notification System : After every successful order placement, payment, and shipment, notifications (Email or SMS) must be sent to the customer. This can be handled by separate services that listen to specific queues.

Let's see the comparison in 7 points:

Communication Style:

• Message Broker : Message brokers facilitate asynchronous communication between different components or services in a distributed system. They allow components to send and receive messages without needing to know the specific destination or timing of the communication.
• REST API : REST APIs facilitate synchronous communication over HTTP/HTTPS. Clients make explicit requests to specific endpoints (URLs) on a server, and the server responds to those requests.

Communication Pattern:

• Message Broker : Typically, message brokers follow the publish-subscribe or point-to-point messaging patterns. Publish-subscribe allows multiple subscribers to receive messages, while point-to-point ensures that a message is consumed by only one receiver.
• REST API : REST APIs are based on a request-response pattern, where a client sends a request to a specific endpoint, and the server responds with data or performs an action.

Asynchronicity:

• Message Broker : Message brokers are well-suited for asynchronous communication. Messages can be sent and processed independently of each other and at different times.
• REST API : REST APIs are primarily synchronous, meaning the client waits for a response from the server after making a request. While asynchronous patterns can be implemented using techniques like polling or WebSockets, REST’s default behavior is synchronous.

Use Cases:

• Message Broker : Message brokers are often used in scenarios where decoupling between components is essential, such as event-driven architectures, message queues for background processing, and inter-service communication in microservices architectures.
• REST API : REST APIs are commonly used for client-server interactions over the web, including accessing resources like databases, web services, or providing access to business logic and data.

Data Format:

• Message Broker : Messages can use various data formats, including JSON, XML, or binary data, depending on the broker and message format specifications.
• REST API : REST APIs often use JSON or XML for data serialization, but they are not limited to these formats.

Scalability:

• Message Broker : Message brokers can provide a high degree of scalability by distributing messages to multiple consumers, making them suitable for handling bursts of traffic or load balancing.
• REST API : REST APIs can be scaled by deploying multiple instances of the API server behind a load balancer, but they may not be as naturally suited for managing large-scale asynchronous workloads.

Complexity:

• Message Broker : Implementing and managing message brokers can be more complex, especially in scenarios with complex routing, message filtering, and ensuring message delivery guarantees.
• REST API : REST APIs are generally easier to develop and understand, making them a popular choice for building web-based applications and services.

In real-world applications, you will likely encounter complex scenarios that require advanced integrations and the usage of message broker.

To navigate these complexities, it’s crucial to have a solid understanding of message broker’s underlying concepts. As you dive deeper into message broker, you’ll find it to be an incredibly versatile tool, capable of handling a wide range of messaging needs, and ultimately helping you build scalable, decoupled, and resilient applications.