Architecture Files #33 · Part of Binary and Beyond. LinkedIn newsletter edition follows.
Coupling is not a moral failure.
Hidden coupling is an accounting failure.
Systems must connect. Orders talk to inventory. Billing talks to entitlements. Partners talk to you through whatever shape Tuesday allowed. The cost appears when those connections are real but undocumented, unowned, and discovered only when a release breaks a consumer nobody knew existed.
You are not paying for integration. You are paying compounding interest on a protocol that never admitted it was a protocol.
The change that should have been local
Picture a mid-market subscription platform. Billing owned a subscriptions table. Growth read it for trial flags. Support wrote notes into a JSON column "temporarily." A nightly job in ops flipped a status code when dunning succeeded. Nobody called this an API. Everyone depended on it.
A billing engineer renamed a status from past_due to past-due for consistency with a new enum style. Tests in billing passed. The deploy was small. By afternoon, growth dashboards under-counted trials, dunning stopped flipping accounts, and support macros that key off the old string flooded the queue.
The postmortem blamed "insufficient communication." That diagnosis is incomplete. Communication was required because the coupling was invisible. Visible coupling would have been a contract change with consumers, versioning, and a migration. Invisible coupling made a string rename into a cross-team incident (The Problem with Shared Databases, Data Contracts Matter More Than APIs).
The table was shared. The protocol was tribal. The interest came due on a Thursday.
A week later, the same estate produced a quieter tax: a hire spent three days learning which columns were "safe" to touch by asking around. No incident. Still a cost. Hidden coupling bills through payroll as often as through pager duty.
Where hidden coupling lives in production
It rarely announces itself as architecture. It shows up as:
Shared tables used as integration. Multiple services read and write the same rows with incompatible assumptions about nulls, locks, and meaning (The Problem with Shared Databases).
Implicit status codes. Integers and strings whose meaning lives in Slack, a retired Confluence page, or one engineer's memory.
Shadow protocols. CSV drops, email parsers, spreadsheet columns, and "temporary" sync jobs that became load-bearing.
Hidden temporal coupling. Job A must finish before job B, enforced only by cron luck and institutional anxiety.
UI-as-API. Another team scrapes or clicks through a screen because no interface was offered, then your redesign becomes their outage.
Copy-paste contracts. The same mapping logic duplicated in three repos, diverging one bugfix at a time.
Each form taxes every release: more reviewers who must be invited by folklore, more regression surface, more fear. Each form taxes hiring: new engineers learn the graph by breaking it. Each form taxes modernisation: you cannot extract what you cannot see (The Economics of Technical Debt, Why CRUD Stops Scaling Before Databases Do).
Why hiding it feels rational (and still compounds)
Teams hide coupling for understandable reasons. Explicit interfaces feel slow. Shared tables feel fast. A status code feels cheaper than a schema. A nightly job feels easier than an event. Under a deadline, those bets often are correct for the quarter.
The economics break when the temporary protocol becomes permanent without a name, an owner, or a version. Interest then accrues as:
- Longer change lead time for "simple" fields
- Incidents that cross team boundaries without a contract to blame
- Refactors that stall because blast radius is unknown
- Political fights about who may touch the sacred table
- Dual-run bridges that never retire
You did not avoid coupling. You avoided paying the documentation and ownership cost up front. Production collects later, with fees.
There is also a cultural incentive. Teams that move "fast" by writing into a neighbour's table look productive on a quarterly scorecard. Teams that propose a contract look slow. Leadership that only measures feature throughput silently rewards hidden coupling. Then the same leadership asks why every small change needs a cross-functional war council. The war council is the interest payment.
A mental model: make the tax visible
All coupling has a cost. Explicit coupling puts the cost on the books: an interface, a consumer list, a compatibility policy, a migration plan. Hidden coupling puts the cost in variance: surprise incidents, surprise reviewers, surprise "we can't ship until finance checks the spreadsheet."
Use a simple test. If changing a field requires hoping you know the consumers, the coupling is hidden. If changing a field requires updating a named contract and notifying named consumers, the coupling is explicit. Explicit is not free. It is priced.
Prefer:
- Versioned events or APIs over shared mutable tables for cross-team integration
- Owned glossaries for statuses over folklore
- Documented job dependencies over cron archaeology
- Explicit dual-run rules over accidental dual writers
You will still couple. You will just stop pretending the coupling is local when it is systemic.
Implications for releases, hires, and modernisation
Put consumer discovery on the critical path for shared surfaces. If a table or topic has unknown readers, finding them is feature work, not optional hygiene.
Price hidden coupling in roadmap language executives understand: days added per change, incident clusters, blocked extractions. "We need cleaner architecture" loses. "This status string is an undeclared API with six consumers" can win budget (The Economics of Technical Debt).
Onboard with maps, not scavenger hunts. A new hire should find the load-bearing protocols in a diagram and a contract repo, not in their first production incident.
On legacy modernisation programmes, we treat hidden coupling as the highest-interest debt: make the protocol explicit first (even if ugly), then migrate behind the contract. Rewriting without revealing consumers just relocates the surprise.
Do not demand zero coupling. Demand that coupling can be named, owned, versioned, and retired.
When you cannot afford a full interface yet, at least publish the shadow protocol: who writes, who reads, what fields matter, what happens on duplicate or late runs. A one-page contract with an owner beats a "temporary" sync that only one person understands. Explicit ugliness is cheaper than invisible elegance that never existed.
A hidden-coupling audit (one pass)
- List shared databases, tables, or buckets touched by more than one team. Who owns the schema meaning?
- List status codes and flags read outside the owning service. Where is the glossary, and is it enforced?
- List jobs, files, emails, or sheets that move business state. What fails if they run late or twice?
- For the last five "small" production incidents, how many crossed an undeclared consumer?
- Which extractions or refactors are blocked because blast radius is unknown?
- For each hidden protocol, what is the smallest explicit contract that would make the next change safe?
- Who is accountable for retiring temporary bridges, and what trigger forces the retirement?
If the audit produces shrugs, you have found the interest rate. Pay it down by making one protocol explicit at a time, starting with the one that taxes every release.
Fingerprint of coupling you can afford
Healthy systems still have seams. The difference is boredom. A status change triggers a known consumer checklist. A schema migration has a version and a sunset. A dual-run has an end date. New engineers ask "which contract?" instead of "who knows what this column means?"
Hidden coupling feels like speed until it feels like molasses. Explicit coupling feels like ceremony until it feels like shipping without a séance.
Make the protocol visible, or keep paying compound interest every time someone renames a string.
Related reading
- The Problem with Shared Databases
- The Economics of Technical Debt
- Data Contracts Matter More Than APIs
- Why CRUD Stops Scaling Before Databases Do
Architecture Files #33 · Part of Binary and Beyond. LinkedIn newsletter edition follows. Surfacing hidden protocols before they tax every release? Start a conversation.