Coupling

Coupling measures how much one module depends on another's internals. Interview-level analysis covers compile-time coupling (shared types, libraries), runtime coupling (synchronous calls, shared databases), data coupling (shared schemas), temporal coupling (coordinated timing), and organizational coupling (teams that must release together).

Lower coupling enables independent change but increases integration cost. The goal is not zero coupling — it is placing coupling at stable, well-owned boundaries.

On interviews: classify coupling types in a given diagram, explain which boundaries reduce change risk, and justify where tight coupling is acceptable (e.g., within a bounded context).

Common pitfalls: hiding coupling behind a shared database; assuming HTTP makes services independent; ignoring that shared libraries recreate monolith release trains.

Checklist:

• List coupling types present in the design.
• Identify which changes force coordinated releases.
• Propose boundaries that absorb volatility.
• Accept intentional coupling only with clear ownership.