Data replication and synchronization strategies keep related data consistent across microservices that each maintain their own local copy, without requiring a shared database.
Key Points: • Event sourcing stores every change to data as an immutable sequence of events; other services subscribe to that event stream and apply the changes to update their own local data. • Change Data Capture (CDC) tools (like Debezium) watch a service's database transaction log and stream any row-level changes to other services in near real time, without the source service needing to explicitly publish events. • CDC decouples data replication from application code, since it works directly off the database's write-ahead log rather than requiring the service to remember to emit events. • Event sourcing gives a full audit trail and the ability to rebuild state at any point in time, at the cost of more complex query patterns. • Both approaches enable eventual consistency across services without tight coupling or a shared database, but require handling out-of-order or duplicate delivery.
Example: Using Debezium, changes to the Orders table in the Order Service's PostgreSQL database are captured from the write-ahead log and streamed to Kafka, letting the Shipping Service keep its own local read-optimized copy of order data in sync without ever querying the Order Service's database directly.
Interview Tip: A concise interview answer is:
"I'd use event sourcing when I want a full history of changes that other services can replay, and Change Data Capture with something like Debezium when I want to stream database changes to other services without modifying application code. Both keep services in sync asynchronously without coupling them to a shared database."