The Top Five Ways for Two Back-end Systems to Communicate using Apache Pulsar
Apache Pulsar plays a critical role in the communication between two back-end systems.
Back-End Communication Using Databases
For most web applications, the back-ends communicate with each other using the database. For example, a web application for an online retail store would contain the following micro-services, along with their function:
- Account Service – Stores all the user’s details in the database
- Shipping Service – Stores all the shipping related details in the database
- Order Service – Stores all the order related details in the database
- Warehouse Service – Stores all the warehouse details in the database
When a customer uses the web application to order an item, the information needs to be stored in the order table. The item then needs to be shipped, and this information stored as well. For everything to run smoothly, the micro-services need to communicate with different databases to fulfill the order.
You can implement this same type of architecture using Apache Pulsar.
With Pulsar, it is easy to process the order as the entire communication is asynchronous. Once a customer places their order, the message is written to a Pulsar topic. Thanks to Pulsar, the message can be received at the warehouse service where the order can begin preparations. It will also be received at the shipping service where the shipping label can be created, and the shipping company will be notified to pick-up the package. All of this information is stored in the database.
Back End Communication Using Rest API
REST API is one of the most popular and important architectures for creating web services, as it provides interoperability between multiple systems. Apache Pulsar’s scalable architecture is able to integrate back-end systems.
The UI layer of the front-end of the web application calls the web services layer, which then publishes the message on the Pulsar layer. The consumer application is also a rest service, and the consumer REST API will then read the topic and perform the appropriate action.
Back End Communication Using Event-Driven Architecture
An Event-driven architecture is popular for communication between two back-end systems that communicate based on the events. Your application produces an event and the consumer application then consumes the events.
You can implement the event-driven architecture using Apache Pulsar. For example, the producer application sends the events to Pub/Sub topic regarding the successful order completion. You can create a consumer application that allows the consumer to subscribe to email or text notification. The producer application produces an event and writes it to the topic. The consumer application then consumes the events and the customer receives notification based on the configuration.
Back End Communication Using Message Queue Architecture
Most large-scale systems use message-based architecture. You can consider the different types of queues, such as FIFO, Dead Letter Queue, etc.
The producer application produces several messages and inserts the messages on one of the message broker topics. These messages are then stored on the storage wall.
The consumer applications consume the messages from the topics, and once the message is consumed, it is removed from the message topic. This will ensure the same messages are not consumed twice.
We can also implement a failed topic, so if the message is not successfully consumed, it will enter into the failed topic. You can implement the consumer application that processes the failed messages, or at a minimum, notifies the administrator.
Backend Communication Using Event Sourcing
You can also configure Apache Pulsar to work with the event sourcing system. For example, let’s say you have a retail application for a data warehouse. This retail application sends out a notification to the consumer once the product has shipped.
You can create the event topic once the product is shipped, and the event objects ensure the consumer application consuming the message attaches the shipping information to the notification.
Message delivery is the most critical functionality of Apache Pulsar, and you can configure it in the following ways:
- At-Most-Once – This means the message is sent to the connector, which will only process the message one time.
- At-Least-Once – This means the message is sent to the connector, which will process the message at a minimum of one time.
- Effectively Once – This means the source system sends the message to the connector, which has a direct output associated with it.