What is eventual consistency and how do microservices handle it?

Expected Interview Answer

Step-by-Step Explanation

1. Step 1

   Accept independent data ownership

   Recognize that each microservice owns its database, so a single ACID transaction cannot span all of them.

2. Step 2

   Propagate changes as events

   When a service commits a change, publish a domain event so other services can update their own copies asynchronously.

3. Step 3

   Use the transactional outbox

   Write the event into an outbox table in the same local transaction as the data change so the event is never lost.

4. Step 4

   Make consumers idempotent

   Design event handlers to apply an update once even if the message is redelivered, preventing double-processing.

5. Step 5

   Reconcile and detect drift

   Add retries, dead-letter queues, and periodic reconciliation jobs to catch and repair any state that failed to converge.

6. Step 6

   Communicate staleness to clients

   Where needed, expose read-your-writes handling or messaging so users understand data may be briefly out of date.

Code Example

// Producer: write data and event in one local transaction
await db.transaction(async (tx) => {
  await tx.orders.insert(order)
  await tx.outbox.insert({ type: 'OrderCreated', payload: order })
})

// Consumer: apply the event exactly once
bus.on('OrderCreated', async (event) => {
  if (await processed.has(event.id)) return // idempotency guard
  await inventory.reserve(event.payload)
  await processed.add(event.id)
})

Follow-up Questions

• How does the transactional outbox pattern prevent lost events?
• What is the difference between strong and eventual consistency?
• How do you give users read-your-writes consistency?
• How does eventual consistency relate to the CAP theorem?
• How do you detect and repair data that never converges?