Bird
Raised Fist0
Microservicessystem_design~12 mins

Eventual consistency in Microservices - Architecture Diagram

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
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.

Practice

(1/5)
1. What does eventual consistency mean in microservices?
easy
A. Data updates will be visible to all parts of the system after some delay
B. Data is always instantly consistent across all services
C. Data is never synchronized between services
D. Data updates happen only during system maintenance

Solution

  1. Step 1: Understand the meaning of eventual consistency

    Eventual consistency means data changes are not immediate but will propagate over time.

  2. Step 2: Compare options with the definition

    Only Data updates will be visible to all parts of the system after some delay correctly states that data updates become visible after some delay, matching eventual consistency.

  3. Final Answer:

    Data updates will be visible to all parts of the system after some delay -> Option A

  4. Quick Check:

    Eventual consistency = delayed data visibility [OK]
Hint: Eventual means "eventually", not instantly [OK]
Common Mistakes:
  • Confusing eventual consistency with immediate consistency
  • Thinking data never syncs
  • Assuming updates only during maintenance
2. Which of the following is a correct way to implement eventual consistency in microservices?
easy
A. Use synchronous HTTP calls between services for every update
B. Use asynchronous event messaging to propagate changes
C. Block all reads until all writes complete
D. Disable communication between services

Solution

  1. Step 1: Identify communication style for eventual consistency

    Eventual consistency relies on asynchronous communication to allow updates to propagate over time.

  2. Step 2: Evaluate options

    Only Use asynchronous event messaging to propagate changes uses asynchronous event messaging, which fits eventual consistency. Others use synchronous or block reads, which do not.

  3. Final Answer:

    Use asynchronous event messaging to propagate changes -> Option B

  4. Quick Check:

    Asynchronous messaging = eventual consistency [OK]
Hint: Eventual consistency needs async events, not sync calls [OK]
Common Mistakes:
  • Choosing synchronous calls which block updates
  • Blocking reads causing poor availability
  • Ignoring communication between services
3. Consider a microservice system where Service A updates data and publishes an event. Service B listens and updates its copy asynchronously. What is the expected state of Service B immediately after Service A's update?
medium
A. Service B has stale data until it processes the event
B. Service B rejects the update
C. Service B has the updated data instantly
D. Service B crashes due to inconsistency

Solution

  1. Step 1: Understand asynchronous event propagation

    Service B updates data only after receiving and processing the event from Service A, which takes time.

  2. Step 2: Determine Service B's state immediately after Service A's update

    Since event processing is asynchronous, Service B still holds old data until it processes the event.

  3. Final Answer:

    Service B has stale data until it processes the event -> Option A

  4. Quick Check:

    Async update means stale data initially [OK]
Hint: Async updates cause temporary stale data [OK]
Common Mistakes:
  • Assuming instant data sync
  • Thinking services reject updates
  • Believing system crashes on inconsistency
4. A microservice system uses event-driven updates but sometimes Service B never receives events from Service A, causing stale data. What is the best fix?
medium
A. Switch to synchronous calls only
B. Ignore the problem as eventual consistency tolerates it
C. Implement event retry and dead-letter queues
D. Stop Service B from reading data

Solution

  1. Step 1: Identify problem cause

    Missing events cause stale data because messages are lost or not delivered.

  2. Step 2: Choose solution to ensure event delivery

    Implementing retries and dead-letter queues helps guarantee events reach Service B or are logged for manual handling.

  3. Final Answer:

    Implement event retry and dead-letter queues -> Option C

  4. Quick Check:

    Retries fix lost events = better consistency [OK]
Hint: Use retries and dead-letter queues for reliable events [OK]
Common Mistakes:
  • Switching to sync calls losing scalability
  • Ignoring lost events causing stale data
  • Disabling reads instead of fixing events
5. You design a microservices system with eventual consistency. Service A updates inventory and publishes events. Service B updates order status based on inventory events. How do you ensure order status eventually matches inventory without blocking user requests?
hard
A. Store all data in a single database to avoid events
B. Make Service B synchronously call Service A for every order update
C. Block user requests until all services are consistent
D. Use asynchronous event processing with idempotent handlers and retries

Solution

  1. Step 1: Understand requirements for eventual consistency and availability

    The system must update order status eventually without blocking user requests, so async processing is needed.

  2. Step 2: Choose design that supports async updates safely

    Using asynchronous event processing with idempotent handlers and retries ensures updates happen reliably and without blocking.

  3. Step 3: Evaluate other options

    Synchronous calls or blocking requests reduce availability; single database removes microservices benefits.

  4. Final Answer:

    Use asynchronous event processing with idempotent handlers and retries -> Option D

  5. Quick Check:

    Async + idempotent + retries = safe eventual consistency [OK]
Hint: Async with retries and idempotency ensures safe updates [OK]
Common Mistakes:
  • Blocking user requests hurting availability
  • Using sync calls causing tight coupling
  • Ignoring idempotency causing duplicate updates