Common Coupling

When several independently deployed components read and write the same mutable store — a table, a cache, a file, a global — they are commonly coupled. Each participant's assumptions about that state become constraints on every other participant, and unlike an interface, there is nothing that declares what those assumptions are.

Why it matters

It is the only common form of coupling whose cost grows with the pairs of participants rather than with the participants themselves. Two teams sharing a table is manageable. Six teams sharing a table produces a schema nobody can change, because a safe change requires knowing every read path in six codebases plus every ad-hoc job that grew up around them.

It is also the form that is easiest to create accidentally. Nobody designs it; it emerges one convenient query at a time.

Implementation patterns

The resolution ladder, in ascending cost — and the discipline is to climb it in order rather than jump to the bottom rung:

1. Assign ownership. One team owns the table and approves schema changes. Costs nothing, stops the worst of it immediately, and is skipped because it sounds like process rather than architecture.
2. Give the other teams a read contract — an API, a read replica, or a change-data-capture projection they own and can shape. Reads are usually the majority of the traffic and the easy half.
3. Move writes behind the owner's interface. The expensive step, and the one that actually removes the coupling.
4. Split the store, but only once access patterns have genuinely diverged. Splitting before ownership gives you the same problem across two tables plus a distributed join.

Industry example

A marketplace at Meesho's growth rate accumulates catalogue, pricing, order and logistics teams all reading and writing one product table. The characteristic symptoms arrive in order: columns that nobody dares delete because nobody can prove they are unread; a NOT NULL added by one team breaking a nightly job owned by another; a long catalogue backfill holding locks that stall order writes so the order team sees a database incident with no application cause; and finally semantic divergence, where status = 3 means one thing to logistics and another to payments, breaking nothing and quietly corrupting reporting.

Failure scenarios

• Migration paralysis. The schema freezes because no change can be proven safe.
• Lock contention across unrelated business functions, producing incidents with no local cause.
• Silent semantic forks, the most dangerous, because no test fails and no schema breaks.
• A decomposition that moves the coupling onto the network — services split, database still shared — which is strictly worse, because now it is invisible and distributed.

Trade-offs

A shared database is genuinely the right answer at small scale. It gives transactional consistency across the whole domain for free, which is a large benefit and the reason it is chosen. The problem is that it has no warning signal: it works until the team count crosses a threshold, and by then the migration is expensive.

The cheap insurance is ownership plus a read contract, adopted early, long before the split is needed. It costs almost nothing and it converts a future rewrite into a future refactor.

Interview question

"Four teams share one product table and each deploys schema changes independently. Walk me through what you would do in the first week, the first quarter, and the first year — and tell me which step you would skip if you only had budget for one."