Your shared database is a failure cascade waiting to take place
Stop being polite. Your shared database is a failure cascade waiting to happen.
Many engineers avoid hard technical choices to stay in a polite, neutral zone. They fear confrontation.
I will be blunt. If you are trying to be neutral on architecture, you are 100% wrong. You are being intellectually dishonest.
The illusion of interfaces
You can define interfaces until you are blue in the face. But if you share a database across a component boundary, you are not modular. You are tightly coupled.
A shared database is a "welded joint." If you cross that boundary, you have created a direct path for a failure cascade. If one component breaks, the entire system is ready to fall.
True independence
Independence means modules evolve daily without disrupting the composite system. Sharing data sources violates this at a fundamental level.
True modularity requires separation at the data layer. If your module needs data from a foreign component, use a clean interface to fetch it. Never use a shared table as a shortcut.
The "Strategy of the Cut"
- Map handoffs. Identify where your code crosses into another component's storage.
- Accept friction. Stop trying to be neutral. Decoupling is hard, but it is necessary for survival.
- Decouple one thing this week. Give the module its own storage.
The goal is to build a system that does not collapse under its own weight.
Discussion starter
At what point do you stop accepting "polite" architecture and start the "Strategy of the Cut"? How are you handling data separation when it is inconvenient?
This hits harder than most people realise.
In trading systems it’s rarely the logic that breaks first, it’s the shared state. Everything looks clean on paper, then one component stalls and suddenly you’ve got decisions being made on stale or partial data.
The worst part is it doesn’t fail loudly. It just drifts until something expensive happens.
Agree on the cut. Most teams wait until they’ve already paid for not doing it.