Event-Driven Architecture
Use an event-driven, eventually consistent approach to maintain data consistency across services.
Intent & Description
⚠️ Problem
How to maintain data consistency across services?
📋 Context
You have applied the Database per Service pattern. Each service has its own database. Some business transactions, however, span multiple services so you need a mechanism to ensure data consistency across services. For example, imagine you are building an e-commerce store where customers have a credit limit. The application must ensure that a new order will not exceed the customer’s credit limit. Since Orders and Customers are in different databases owned by different services, the application cannot simply use a local ACID transaction.
💡 Solution
Use an event-driven, eventually consistent approach. Each service publishes an event whenever it updates its data. Other services subscribe to events. When an event is received, a service updates its data. This approach decouples services and enables asynchronous communication, improving scalability and resilience.
Real-world Use Case
Source
Advantages
- Enables loosely coupled services that can be developed, deployed, and scaled independently
- Improves availability since services don’t need synchronous communication
- Supports multiple subscribers for each event without modifying the producer
- Naturally captures the history of state changes as a sequence of events
Disadvantages
- Programming model is more complex than traditional ACID transactions
- Eventual consistency may be confusing to users or require compensating logic
- Events may be delivered out of order or duplicated, requiring idempotent consumers
- Debugging and tracing distributed event flows is more difficult