Field Notes
When a shared database is not a shared understanding
Multiple services reading the same tables often means nobody owns the invariants. How we surface that during an architecture review.
Teams rarely set out to create a distributed monolith. They start with one schema, then extract a service while leaving the tables in place “for now.” Months later, three codebases write to the same rows with three different notions of valid state.
During a Backend Architecture Review we ask a blunt question of every shared table: who may refuse a write? If the answer is “whoever gets there first,” the invariant lives nowhere.
Useful evidence includes:
- Migration history that shows columns added for one service’s convenience without a corresponding owner document
- Background jobs that “fix” data after another service wrote something odd
- Integration tests that only ever run against an empty database
The remedy is not always a dramatic split. Sometimes it is naming a single writer, introducing an explicit reservation record, or accepting a read-only replica with a published contract. The review’s job is to make the choice visible before peak traffic does.