Baemin, a South Korean food delivery service owned by Delivery Hero, successfully navigated the challenges of rapid customer member growth by moving from a monolithic architecture to a more flexible event-driven microservices-based system.
As a recent Delivery Hero blog post shared, a cornerstone of the Baemin system is an event-driven architecture. The architecture's standout features include the meticulous separation of concerns through layered event subscribers and the use of event storage for reliability. Utilizing a common Relational Database Management System (RDBMS) and employing the Transactional Outbox Pattern, Baemin has built a robust framework that's scalable and dependable.
Initially, Baemin grappled with the limitations of a monolithic architecture, which became increasingly evident as the company scaled. The system was unable to handle the surge in traffic and orders, leading to a plethora of errors. The move to microservices was completed in November 2019, setting the stage for the next phase: adopting an event-driven architecture. This architecture was crucial for achieving loose coupling among various microservices, enhancing system resilience and flexibility.
The essence of Baemin's event-driven architecture lies in publishing domain events rather than commands or requests. This subtle but critical distinction allows for a reduction in dependencies between different systems. In a traditional command-based system, changes in one service could necessitate changes in another, leading to a tightly coupled architecture. By focusing on domain events, Baemin ensures that each microservice operates independently, subscribing to events that are relevant to its domain.
In Baemin's event-driven architecture, events and subscribers are organized into three layers to ensure modularity and scalability. The first layer, the Application Events & First Subscriber Layer, leverages the Spring Framework's Application Event to manage internal, domain-specific tasks and publishes these events via AWS Simple Notification Service (SNS). The second layer, Internal Events & Second Subscriber Layer, handles tasks that are not core to the domain but are nonetheless essential. For example, in a login process, this layer takes care of secondary tasks like logging out from other devices. Finally, the third layer, called External Events & Third Subscriber Layer, is designed to publish events that external systems will consume. These events are generalized to avoid creating dependencies with external systems. This layered approach allows Baemin to maintain a loosely coupled architecture while ensuring that each microservice can operate independently.
One of the challenges in an event-driven architecture is ensuring the reliability of event publication. Baemin addresses this through the introduction of an event storage system. This storage system uses the same Relational Database Management System (RDBMS) as its domain storage, thereby ensuring data consistency through transactions. The event storage serves as a buffer, capturing events and ensuring they are reliably published.
The architecture employs a Transactional Outbox Pattern to ensure data consistency and reliable event publication. This pattern uses the same storage for both domain and event data, allowing for a reliable event publication mechanism. The following diagram in the article illustrates the final design, showcasing the interaction between different types of events, the event storage system, and the subscriber layers.
[Click on the image to view full-size]
Nevertheless, the final design is noteworthy for its meticulous separation of concerns through different layers of event subscribers. The use of event storage to ensure reliability and the focus on domain events for loose coupling are standout features.
In summary, Baemin's architectural transformation offers rich insights for organizations grappling with scaling issues. By layering its event subscribers and leveraging event storage backed by a common RDBMS, Baemin has crafted a system that not only meets its current needs, but is also well-suited for future scalability and enhancements.