Distributed systems • 4 minute read
Complexity does not disappear. It changes address.
Every architectural simplification moves responsibility somewhere else. Good design makes the new cost explicit.
Optimization is a trade, not a deletion
Removing coordination can improve independence while introducing eventual consistency. Removing a single point of failure can improve availability while introducing partial failures. Scaling horizontally can increase capacity while adding retries, duplicate work, ordering problems, and network latency.
The decision is not whether complexity exists. It is which complexity the system and its operators can afford.
Track where the cost moved
- Consistency: What can be temporarily stale, and what cannot?
- Failure: Which components can fail independently, and how is that state exposed?
- Repetition: Which operations may run more than once, and how are they made safe?
- Ordering: Which events require sequence, and what happens when they arrive late?
- Recovery: Who or what restores useful state after a partial failure?
Review failure paths before celebrating the happy path
A happy path demonstrates capability. A failure path reveals operational character. Before accepting an architectural change, document the benefit, the displaced complexity, the detection signal, the recovery mechanism, and the owner of unresolved exceptions.
A compact decision record
- What becomes simpler?
- Where does the removed responsibility reappear?
- How will the new failure mode be observed?
- What is the recovery path?
- Why is this trade acceptable for this system?
Evidence boundary
This note documents my personal system-design heuristic adapted from my public LinkedIn post. It does not describe a specific production incident, employer architecture, or measured outcome.