0
0
Microservicessystem_design~12 mins

Eventual consistency in Microservices - Architecture Diagram

Choose your learning style9 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale
System Overview - Eventual consistency

This system demonstrates how multiple microservices keep data consistent over time without immediate synchronization. It ensures that updates in one service eventually reflect in others, allowing the system to remain available and scalable despite temporary data differences.

Architecture Diagram
User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
+----------------+      +----------------+      +----------------+
|  Service A     |<---->|  Message Queue |<---->|  Service B     |
| (Order Service)|      | (Event Broker) |      | (Inventory Svc)|
+----------------+      +----------------+      +----------------+
       |                                         |
       v                                         v
+--------------+                          +--------------+
| Database A   |                          | Database B   |
+--------------+                          +--------------+
       |                                         |
       v                                         v
+--------------+                          +--------------+
| Cache A      |                          | Cache B      |
+--------------+                          +--------------+
Components
User
user
Initiates requests to the system
Load Balancer
load_balancer
Distributes incoming requests evenly to API Gateway instances
API Gateway
api_gateway
Routes requests to appropriate microservices
Service A (Order Service)
service
Handles order creation and updates
Service B (Inventory Service)
service
Manages inventory updates based on orders
Message Queue (Event Broker)
message_queue
Asynchronously transfers events between services to enable eventual consistency
Database A
database
Stores order data for Service A
Database B
database
Stores inventory data for Service B
Cache A
cache
Speeds up read access for order data
Cache B
cache
Speeds up read access for inventory data
Request Flow - 12 Hops
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Service A (Order Service)
Service A (Order Service) → Database A
Service A (Order Service) → Cache A
Service A (Order Service) → Message Queue (Event Broker)
Message Queue (Event Broker) → Service B (Inventory Service)
Service B (Inventory Service) → Database B
Service B (Inventory Service) → Cache B
Service A (Order Service) → API Gateway
API Gateway → Load Balancer
Load Balancer → User
Failure Scenario
Component Fails:Message Queue (Event Broker)
Impact:Order events are not delivered to Inventory Service, causing inventory data to become stale and inconsistent temporarily.
Mitigation:Implement message queue replication and persistent storage to avoid message loss. Use retry mechanisms and dead-letter queues to handle failures.
Architecture Quiz - 3 Questions
Test your understanding
Which component ensures that updates from Service A eventually reach Service B?
ALoad Balancer
BMessage Queue (Event Broker)
CCache A
DAPI Gateway
Design Principle
This architecture uses asynchronous messaging to achieve eventual consistency between microservices. It balances availability and scalability by allowing services to operate independently and synchronize data over time, avoiding tight coupling and immediate blocking calls.