Data consistency challenges in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Eventual Consistency in Microservices

In a microservices system using asynchronous messaging, what is the main characteristic of eventual consistency?

A Data is never synchronized between services.

B All services have the same data instantly after an update.

C Services may temporarily have different data but will converge eventually.

D Services update data only when manually triggered.

💡 Hint

Think about how data synchronization happens over time in distributed systems.

Eventual consistency means that after some time, all services will have the same data, but not immediately after an update.

❓ Architecture

intermediate

Choosing a Data Consistency Model for Inventory Service

You design an inventory microservice that must reflect stock changes immediately to avoid overselling. Which consistency model suits best?

A Eventual consistency with asynchronous updates.

B Manual reconciliation after batch updates.

C No consistency, allow stale reads.

D Strong consistency with synchronous database transactions.

💡 Hint

Consider the risk of selling items that are not in stock.

Strong consistency ensures immediate data accuracy, preventing overselling by synchronously updating stock.

❓ scaling

advanced

Scaling a Microservices System with Consistency Constraints

When scaling a microservices system that requires strong consistency, what is a common tradeoff?

A Unlimited throughput without delays.

B Higher latency due to synchronous coordination.

C No need for distributed locks or consensus.

D Instant data replication without network overhead.

💡 Hint

Think about what synchronous coordination requires across services.

Strong consistency often requires coordination like distributed locks, which increases latency and limits throughput.

❓ tradeoff

advanced

Tradeoffs Between Eventual and Strong Consistency

Which statement correctly describes a tradeoff between eventual and strong consistency in microservices?

A Eventual consistency provides lower latency but may show stale data temporarily.

B Strong consistency always improves system availability.

C Eventual consistency requires synchronous database transactions.

D Strong consistency eliminates all network delays.

💡 Hint

Consider latency and data freshness differences.

Eventual consistency reduces latency by allowing temporary stale data, while strong consistency ensures fresh data but with higher latency.

❓ estimation

expert

Estimating Impact of Consistency Model on System Throughput

A microservices system processes 10,000 requests per second. Using strong consistency with synchronous commits adds 10ms latency per request. Estimate the maximum throughput impact compared to eventual consistency with near-zero latency.

A Throughput reduces to about 100 requests per second due to latency.

B Throughput remains at 10,000 requests per second with no impact.

C Throughput reduces to about 1,000 requests per second due to latency.

D Throughput doubles because of synchronous commits.

💡 Hint

Calculate how latency affects requests per second capacity.

10ms latency per request means each request takes longer, reducing max throughput roughly to 100 requests per second (1000ms / 10ms).

Practice

1. What is the main challenge of data consistency in microservices?

easy

A. Ensuring all services see the same data at the same time

B. Writing code in multiple programming languages

C. Deploying services on different servers

D. Using different databases for each service

Solution

1. Step 1: Understand data sharing in microservices

   Microservices often manage their own data, but sometimes share data across services.

2. Step 2: Identify the consistency challenge

   Because data is shared, keeping it the same across services at the same time is difficult.

3. Final Answer:

   Ensuring all services see the same data at the same time -> Option A

4. Quick Check:

   Data consistency = same data view [OK]

Hint: Data consistency means same data visible everywhere [OK]

Common Mistakes:

• Confusing deployment issues with data consistency
• Thinking language differences cause consistency problems
• Assuming different databases alone cause consistency issues

2. Which of the following is a common technique to handle temporary data inconsistency in microservices?

easy

A. Using synchronous database locks across services

B. Disabling network retries to avoid duplicate messages

C. Sharing a single database instance for all services

D. Implementing event-driven communication with retries

Solution

1. Step 1: Review methods to handle inconsistency

   Temporary inconsistencies happen due to delays or failures in communication between services.

2. Step 2: Identify best practice

   Event-driven communication with retries helps services eventually sync data despite temporary failures.

3. Final Answer:

   Implementing event-driven communication with retries -> Option D

4. Quick Check:

   Events + retries = eventual consistency [OK]

Hint: Events and retries fix temporary inconsistency [OK]

Common Mistakes:

• Thinking synchronous locks work well across distributed services
• Assuming one shared database solves all consistency issues
• Disabling retries causes data loss, not consistency

3. Consider two microservices A and B. Service A updates data and sends an event to B. If B processes the event twice due to retry, what is the likely outcome?

medium

A. Data in B will be corrupted due to duplicate updates

B. B will ignore the second event automatically

C. B will apply the update twice unless idempotency is implemented

D. Service A will rollback its update

Solution

1. Step 1: Understand event retries in microservices

   Retries can cause the same event to be processed multiple times by a service.

2. Step 2: Analyze effect without idempotency

   Without idempotency, processing the same event twice causes duplicate updates, leading to incorrect data.

3. Final Answer:

   B will apply the update twice unless idempotency is implemented -> Option C

4. Quick Check:

   Idempotency prevents duplicate effects [OK]

Hint: Without idempotency, retries cause duplicate updates [OK]

Common Mistakes:

• Assuming retries are always ignored automatically
• Thinking service A rolls back on B's retry
• Believing duplicate events never affect data

4. A microservice system uses events to sync data but sometimes data is inconsistent. Which fix addresses this problem?

medium

A. Add idempotent processing for events

B. Store all data in one shared database

C. Use synchronous calls instead of events

D. Remove retries to avoid duplicate events

Solution

1. Step 1: Identify cause of inconsistency

   Retries cause duplicate events, leading to inconsistent data if processing is not idempotent.

2. Step 2: Choose best fix

   Making event processing idempotent ensures duplicates do not corrupt data, fixing inconsistency.

3. Final Answer:

   Add idempotent processing for events -> Option A

4. Quick Check:

   Idempotency fixes duplicate event issues [OK]

Hint: Idempotency fixes duplicate event problems [OK]

Common Mistakes:

• Removing retries causes lost updates
• Switching to synchronous calls reduces scalability
• Using one database breaks microservices independence

5. You design a microservices system where Service A updates inventory and Service B updates orders. Both must stay consistent. Which approach best handles data consistency challenges?

hard

A. Use distributed transactions with two-phase commit across services

B. Use event-driven architecture with eventual consistency and compensating actions

C. Store all data in a single monolithic database

D. Synchronously call Service B from Service A and block until done

Solution

1. Step 1: Understand distributed transaction challenges

   Two-phase commit is complex and reduces scalability in microservices.

2. Step 2: Evaluate event-driven eventual consistency

   Event-driven design with eventual consistency and compensating actions handles failures gracefully and scales well.

3. Step 3: Compare other options

   Monolithic DB breaks microservices independence; synchronous blocking reduces performance.

4. Final Answer:

   Use event-driven architecture with eventual consistency and compensating actions -> Option B

5. Quick Check:

   Event-driven + compensations = scalable consistency [OK]

Hint: Event-driven with compensations scales best for consistency [OK]

Common Mistakes:

• Choosing distributed transactions that hurt scalability
• Using monolithic DB breaks microservices benefits
• Blocking synchronous calls reduce system responsiveness