Coupling and Cohesion

Introduction

Two services at a fintech company deploy independently — or so the team believes. Service A handles account balances. Service B handles transactions. A database table, account_snapshots, is read by both. When Service A’s team changes the schema of that table to add a pending_balance column and restructures how current_balance is computed, Service B’s queries begin returning wrong results. Neither team changed Service B. Neither team broke a test. Production transactions reported incorrect available balances for six hours before anyone traced the cause.

The services were deployed independently. They were not developed independently. They shared state. The coupling was real; it was just invisible.

Thread Activation

You have already seen tradeoffs (T12) examined at infrastructure and system design levels in Books 3 and 4, where every architectural decision involves competing forces. Here the same lens applies at code level, and the central code-level tradeoff is coupling versus cohesion. The shape is the same: no decision is free; every choice to gain one property costs another. Understanding which property to optimise at each boundary is the engineering judgment this chapter develops.