Two services need the same data. Do you share a database, call an API, or replicate?
Quick Answer
Prefer a single owner for each piece of data. If service B needs service A's data: a synchronous API call when B needs it live and A's availability is acceptable; event-driven replication (B keeps a read copy updated from A's events) when B needs it fast/offline and can tolerate eventual consistency. A shared database is the simplest but couples the two services' schemas and deployments — usually a last resort.
My starting principle is that each piece of data has one owning service. So if service B needs service A's data, the question is how B consumes it. If B needs it live and it's fine for B to depend on A being up, a synchronous API call is simplest. If B needs it fast, or needs to work when A is down, then B keeps its own read-only copy that it updates by consuming A's events — the cost is eventual consistency and handling duplicate or out-of-order events. A shared database works and is the least effort, but it couples the two services' schemas and deployments, so I treat it as a last resort. I'd say the trade-off out loud and pick based on how much consistency and coupling the situation can tolerate.
| Approach | Pros | Cons |
|---|---|---|
| Shared database | Simple, consistent, no duplication | Schema coupling, no independent deploys, one team's change breaks another |
| Synchronous API call | Always fresh, single source of truth | B's availability now depends on A; latency; cascading failures |
| Event-driven replica | B is fast and independent, resilient to A being down | Eventual consistency, more infra, must handle out-of-order/duplicate events |
The mature answer names the trade-off explicitly and picks based on consistency needs and coupling tolerance, not dogma. Often: API call for now, move to events if the coupling or load becomes a problem.