Why Eventual consistency handling in Microservices? - Purpose & Use Cases

The Big Idea

What if your system could fix its own data mismatches without slowing down your users?

The Scenario

Imagine you run a small online store where orders, payments, and inventory are all updated by hand in separate spreadsheets. When a customer places an order, you must manually update the stock, confirm payment, and notify shipping. This takes time and mistakes happen often.

The Problem

Manually updating each system one by one is slow and error-prone. If you forget to update inventory or payment status, customers get wrong information. Also, if two people update the same data at once, conflicts arise and cause confusion. This manual approach cannot keep up as your store grows.

The Solution

Eventual consistency handling lets different parts of your system update independently but still reach the same final state over time. Instead of waiting for all updates to finish at once, each service shares changes asynchronously. This reduces delays and errors, making the system more reliable and scalable.

Before vs After

✗ Before

updateInventory();
updatePayment();
updateShipping();

✓ After

publishEvent('OrderPlaced');
// Each service updates itself when it receives the event

What It Enables

It enables large, distributed systems to work smoothly without waiting for every part to update instantly, improving speed and fault tolerance.

Real Life Example

In a ride-sharing app, when a ride is booked, the booking service, payment service, and driver app update separately but eventually agree on the ride status, even if some updates are delayed.

Key Takeaways

Manual updates cause delays and errors in distributed systems.

Eventual consistency allows independent updates that converge over time.

This approach improves system speed, reliability, and scalability.

Practice

1. What does eventual consistency mean in microservices?

easy

A. Services use a single database to avoid inconsistencies

B. All services update data instantly and always stay in sync

C. Data updates may be delayed but will become consistent over time

D. Data is never synchronized between services

Solution

1. Step 1: Understand the concept of eventual consistency

   Eventual consistency means data changes are not immediate but will propagate and become consistent eventually.

2. Step 2: Compare options with the concept

   Only Data updates may be delayed but will become consistent over time describes delayed but eventual synchronization, matching the definition.

3. Final Answer:

   Data updates may be delayed but will become consistent over time -> Option C

4. Quick Check:

   Eventual consistency = delayed sync but consistent later [OK]

Hint: Look for delayed but guaranteed data sync over time [OK]

Common Mistakes:

• Confusing eventual consistency with immediate consistency
• Thinking data never syncs
• Assuming single database means eventual consistency

2. Which of the following is a correct way to handle eventual consistency in microservices?

easy

A. Use asynchronous event messages to update other services

B. Use synchronous calls between services for every update

C. Block user requests until all services are updated

D. Store all data in a single monolithic database

Solution

1. Step 1: Identify the correct communication pattern for eventual consistency

   Eventual consistency relies on asynchronous events to propagate updates without blocking.

2. Step 2: Evaluate options

   Use asynchronous event messages to update other services uses asynchronous event messages, which fits eventual consistency best.

3. Final Answer:

   Use asynchronous event messages to update other services -> Option A

4. Quick Check:

   Asynchronous events = eventual consistency [OK]

Hint: Choose asynchronous event-driven updates, not synchronous calls [OK]

Common Mistakes:

• Choosing synchronous calls which block and reduce scalability
• Thinking blocking user requests is needed
• Assuming monolithic DB solves consistency

3. Consider this simplified event processing code snippet in a microservice:

eventQueue = []

function processEvent(event) {
  if (event.type === 'update') {
    database.update(event.data)
  }
}

// Events arrive asynchronously
processEvent({type: 'update', data: {id: 1, value: 'A'}})
processEvent({type: 'update', data: {id: 1, value: 'B'}})

// What is the likely final value in the database for id 1?

medium

A. The value remains unchanged

B. 'A', because the first event updates the value

C. An error occurs due to conflicting updates

D. 'B', because the second event overwrites the first

Solution

1. Step 1: Analyze event processing order

   Events are processed in order: first update to 'A', then update to 'B'.

2. Step 2: Determine final database state

   The second update overwrites the first, so final value is 'B'.

3. Final Answer:

   'B', because the second event overwrites the first -> Option D

4. Quick Check:

   Last update wins = 'B' [OK]

Hint: Last event update overwrites previous data [OK]

Common Mistakes:

• Assuming first update persists ignoring later events
• Expecting errors on normal overwrites
• Thinking data stays unchanged without updates

4. A microservice uses event-driven updates but sometimes data conflicts occur. Which fix improves eventual consistency handling?

function handleEvent(event) {
  if (event.type === 'update') {
    if (!database.has(event.data.id)) {
      database.insert(event.data)
    } else {
      database.update(event.data)
    }
  }
}

medium

A. Add version numbers to events and apply only newer versions

B. Remove the check and always insert data

C. Process events synchronously to avoid conflicts

D. Ignore conflicting events silently

Solution

1. Step 1: Identify cause of conflicts

   Conflicts arise when updates arrive out of order or duplicate events occur.

2. Step 2: Apply versioning to resolve conflicts

   Using version numbers lets the service apply only the latest update, ensuring consistency.

3. Final Answer:

   Add version numbers to events and apply only newer versions -> Option A

4. Quick Check:

   Versioning resolves conflicts in eventual consistency [OK]

Hint: Use version numbers to apply only latest updates [OK]

Common Mistakes:

• Removing checks causes duplicate inserts
• Synchronous processing reduces scalability
• Ignoring conflicts leads to stale data

5. You design a microservices system where orders and inventory are separate services. To handle eventual consistency, which approach best ensures inventory updates reflect orders correctly despite delays?

hard

A. Store orders and inventory in the same database to avoid syncing

B. Use an event log where order service emits events and inventory service processes them asynchronously with retries

C. Make inventory service call order service synchronously for every update

D. Ignore inventory updates until orders are fully processed

Solution

1. Step 1: Understand the need for asynchronous communication

   Orders and inventory are separate; syncing asynchronously avoids blocking and scales better.

2. Step 2: Choose event log with retries for reliability

   Using an event log lets inventory process order events reliably, handling delays and retries to ensure consistency.

3. Final Answer:

   Use an event log where order service emits events and inventory service processes them asynchronously with retries -> Option B

4. Quick Check:

   Event log + async processing = robust eventual consistency [OK]

Hint: Use event logs with retries for reliable async sync [OK]

Common Mistakes:

• Using synchronous calls causing blocking
• Single database reduces microservices benefits
• Ignoring updates causes stale inventory