Event-Driven Architecture for Scalable Marketplace with RabbitMQ and SSE
The article will guide you through a case study of a successful and performant marketplace built with Feathers.js microservices, event-driven architecture utilizing RabbitMQ with AMQP, and Server-Sent Events notifying connected clients (frontends and hardware appliances).
What is the marketplace? Is it different from other e-commerce sites?
Marketplace is a platform where multiple individual businesses meet to sell their goods and services. Don’t confuse it with an e-shop tied only to one specific business.
What are the key challenges when building a marketplace?
The environment with multiple sellers creates perfect conditions for rapid growth. That involves a lot of new traffic leading to needs for high availability and performance, 3rd party integrations, etc. Some degree of customization options for brand presentation can attract even more business, creating demands for scaling.
Architectural decisions
Based on the abovementioned conditions, the benefits of microservices can be leveraged. But then, communication is another challenge, as a lot is happening on large marketplace platforms. New registrations, product changes, user profile updates, orders, claims… We can consider everything an event — an action triggering another action in multiple places.
Picture: Example - After successful user registration, the notification service sends a welcome email, the benefit service assigns a points balance, and the segment service assigns the user to a group.
Events are everywhere — not only between services
a) Inside a microservice (CRUD operations hooks)
b) Between microservices (asynchronous queues)
c) Outside of microservice (from server to connected clients)
Inside a microservice — hooks
A good service-oriented framework such as Feathers.js provides before and after hooks for entity operations. When a user logs in, the last login timestamp is updated in its profile. When the seller updates the parent product, changes are automatically synchronized to all child products.
Between microservices — RabbitMQ with AMQP
RabbitMQ message broker is often used in the JavaScript tech stack, which is the stack used in this case study. In others, you can encounter, e.g., Apache Kafka.
In this pub/sub-system, events travel through the system as AMQP messages. The payload contains JSON data (e.g., updated user name), and headers contain extra data such as request ID, namespace, etc.
When using topics, user service publishes messages with routing keys such as "user.registered" or "user.updated". Multiple other services can be subscribed for these messages to the whole user topic "user.#" (notification service sending emails) or only a particular event "user.updated" (chat service to sync updated names into user chatrooms).
When one of the services is down for any reason (crash, maintenance, new version release), other parts should not crash nor throw any error. Messages will wait in queues. When the affected service is functional again, it fetches and processes messages from the queue, then sends ACK, marking a message as processed.
Picture: Dead-letter queue with failed messages
In the case of a failure during the processing in the event handler, the message is rerouted to a dead-letter exchange, where all failed messages wait. When the fix is released, they can be rerouted from the dead-letter queue to their original destination queue and finish the operation successfully.
The use of event-based communication between services ensures no data are lost during downtime, there are no timeouts in peaks, and parallel processing can be easily configured with the prefetch parameter value. That’s an upgrade from comparison with traditional HTTP communication where normally, lost data are lost forever, or they are found in logs where it’s difficult to parse them back and execute failed operations.
Outside from microservice
The system notifies connected clients in real-time about important events. Web frontend and mobile application users are notified about planned system maintenance, which displays a warning to the user. Hardware appliance to manage orders and print receipts located in the seller's warehouse is notified about new orders.
Picture: Clients notified via Server-Sent Events (SSE)
Server-Sent Events (SSE) is a lightweight technology that is ideal for these purposes as there is no need for two-way communication. It’s a bit underrated, less known, and less used than WebSockets. SSE have a very straightforward setup with HTTP’s "text/event-stream", debugging is simple, native tooling without additional libraries can be used, and they drain less battery in mobile devices.
Conclusion
The event-based approach is the modern choice for today's fast-paced e-commerce world. During our audits, we noticed multiple outdated architectures that were unprepared for their current business demands. Even today, e-commerce systems with large customer bases are often tightly coupled and crash in peaks because of chained synchronous operations. Examples of such operations are invoice generation, sending notifications, etc. Decouple services to increase reliability and handle load spikes.
