Cross-Service Data Synchronization

When each service owns its data, the question immediately follows: how does service B access data that service A owns? The answer is never "query service A's database." The answer is one of three patterns: API calls, event-driven replication, or materialized views built from events. Each pattern has trade-offs in consistency, latency, and operational complexity.

1. Synchronous API Calls Service B calls service A's API at runtime to fetch the data it needs. The data is always current. The trade-off: service B depends on service A's availability and latency. If service A is down, service B cannot function. Use this pattern sparingly, and always with circuit breakers and fallback behavior.
2. Event-Driven Replication Service A publishes events when its data changes. Service B subscribes and maintains a local copy — a projection optimized for its own access patterns. The data is eventually consistent but locally available. Service B functions independently even when service A is down. This is the pattern that delivers genuine independence.
3. CQRS Read Models A dedicated read service subscribes to events from multiple source services and builds a composite view. The order detail page needs data from the order service, the customer service, and the shipping service. Instead of three API calls at runtime, a read model aggregates the data from events and serves it from a single optimized store.