Two teams need the same customer data. Do you give them one shared database, or two copies that are allowed to disagree?
Answer
Short answer
Name the single writer first, then choose which coupling you would rather own: a shared schema couples the two teams' release calendars, while a replicated copy couples them to a staleness window and obliges someone to detect and repair divergence.
The hidden issue is data ownership. If nobody owns the meaning of the data, a shared database only hides the conflict until two services make different promises about the same record. Strong data ownership means one system is accountable for truth, other systems consume through a contract, and disagreement has a repair path. Weak data ownership lets each team optimise locally while the business discovers the inconsistency downstream.
Data ownership should be visible in the architecture, because data ownership is what keeps a shared record from becoming everybody's and nobody's responsibility.
Was this answer helpful?
Likely follow-ups
- The reading team needs the data to be current to within a second for a billing calculation. Which options does that remove?
- How do you evolve a shared schema when one team needs a breaking change and the other has no capacity this quarter?
- Your replicated copy has drifted and nobody noticed for a month. How would you have found out sooner?
- When is the honest answer that these are one service and the team boundary is wrong?
Related questions
- An upstream team renames a field in the events you consume and nobody tells you. What should your pipeline have done?hardAlso on schema-evolution5 min
- How would you design a data pipeline you can safely re-run?hardAlso on schema-evolution6 min
- How do you roll back a model in production?hardAlso on schema-evolution6 min
- How do you turn what the business tells you into a domain model that holds up once the exceptions arrive?hardAlso on bounded-context7 min