What is the difference between eventual consistency and strong consistency in microservices?

Short answer: Eventual Consistency: In an eventual consistency model, changes to one service may take time to propagate to others. This model allows for temporary inconsistencies, but guarantees that, given enough time, all services will eventually reach a consistent state. This is common in distributed systems because it allows for better availability and performance.

Example code

If an Order Service and Inventory Service are eventually consistent, when an order is placed, the inventory might not be updated immediately, but it will be updated eventually once the event is processed. Strong Consistency: In a strongly consistent system, once a change is made in one service (or database), all other services (or databases) will immediately reflect that change. This model ensures that all services have the same state at any point in time but often at the cost of performance and availability. Example: A banking system where an update to a user’s balance must immediately be reflected across all services to ensure that the balance is never inconsistent.

Real-world example (ShopNest)

After payment succeeds, ShopNest publishes OrderPaid. Inventory and Notification services react independently—no giant distributed transaction.

Say this in the interview

1. Define — one clear sentence (the short answer above).
2. Example — relate it to a project like ShopNest or your real work.
3. Trade-off — when you would not use it.