Ensuring data consistency when multiple microservices update shared data relies mainly on eventual consistency through the Saga pattern, with distributed transactions reserved for cases that truly need strict, immediate consistency.
Key Points: • The Saga pattern lets each service manage its own local transaction and communicate changes to others through events, converging to a consistent state over time. • Eventual consistency favors availability and independence between services, at the cost of a brief window where different services may see slightly different data. • Distributed transactions (such as two-phase commit) can enforce strict, immediate consistency, but they add coordination overhead, reduce availability, and don't scale well across independently owned databases. • Idempotent event handlers and techniques like the outbox pattern are important so retries or duplicate events don't corrupt state during eventual consistency. • The right approach depends on the data: financial balances may justify the extra coordination cost, while denormalized read data can safely use eventual consistency.
Example: When a customer's loyalty tier changes, the Loyalty service updates its own record and publishes a TierChanged event; the Marketing service consumes that event to update its own targeting data asynchronously, rather than the two services sharing a synchronous, distributed transaction.
Interview Tip: A concise interview answer is:
"I'd default to eventual consistency using the Saga pattern, where each service manages its own transaction and communicates changes through events, since that scales better and keeps services independent. I'd only reach for distributed transactions when the data genuinely needs strict, immediate consistency, since the coordination overhead and reduced availability are a real cost."