Data consistency across microservices with separate databases is achieved by replacing cross-service transactions with either the Saga pattern or an event-driven, eventually-consistent approach, since a single ACID transaction can't span multiple databases.
Key Points: • The Saga pattern breaks a business process into local transactions per service, each with a compensating action if a later step fails. • Event-driven consistency has each service publish domain events when its state changes, and other services update their own local copies of the data by reacting to those events. • This trades immediate, strong consistency for eventual consistency, where all services converge to the correct state after a short delay. • Idempotent event handlers and reliable message delivery, such as the outbox pattern, prevent duplicate or lost updates from corrupting state. • Choosing which data needs strong consistency versus which can tolerate eventual consistency is a key design decision, not a one-size-fits-all answer.
Example: When a customer updates their shipping address, the Customer service publishes an AddressUpdated event; the Order service and Shipping service consume that event asynchronously and update their own cached copies of the address, rather than the Order service querying the Customer database directly.
Interview Tip: A concise interview answer is:
"Since each service owns its own database, I rely on the Saga pattern for multi-step business transactions and event-driven updates for keeping local copies of data in sync, accepting eventual consistency instead of a distributed transaction. Reliable delivery patterns like the outbox pattern and idempotent consumers keep that eventual consistency correct."