Design for Change

The Only Safe Assumption

Every requirement in the document will eventually be wrong. Features pivot, traffic patterns invert, vendors die, teams reorganize. Architecture is not the art of predicting the future — it is the art of making future changes cheap.

 RIGID DESIGN                        EVOLUTIONARY DESIGN

 Client ──► App ──► MySQL            Client ──► API contract ──► App ──► Store interface
 (logic, schema, and vendor              │                          │
  fused everywhere)                      ▼                          ▼
                                    swap/add clients freely     swap Postgres → CockroachDB,
 change = rewrite + migration                                  add read store, behind one seam
 + freeze + prayer

The right-hand design pays a small constant cost (an interface, a seam) to buy optionality on every change that follows.

The Mechanisms That Buy Change-Cheapness

1. Contracts at boundaries. Services communicate through versioned APIs and schemas, not shared databases or internals. A boundary behind a contract can be rewritten, re-hosted, or replaced invisibly.

2. Reversible decisions first. Classify decisions by reversal cost:

Cheap to reverse	Expensive to reverse
Library choice behind an interface	Data model of core entities
Service extraction timing	Public API shape
Cache implementation	Partition key choice
Deployment tooling	Vendor-locked managed service with data gravity

Spend design attention inversely: the expensive column deserves the debate.

3. Data ownership clarity. Each datum has one writing owner; everything else reads via contracts. Change then propagates along known edges instead of rippling through shared tables.

4. Config over code for volatility. Things that change often (limits, flags, routing weights) belong in configuration, not redeployment cycles.

The Database Trap

Storage is where change-resistance bites hardest — schemas outlive applications:

 CHANGE-HOSTILE                     CHANGE-TOLERANT
 - business logic in stored procs   - logic in services; DB stores state
 - every feature adds columns to    - domain tables per bounded context;
   one mega-table                     extension tables / JSONB for volatile bits
 - direct cross-service table       - services reach each other's data
   joins                              only via APIs/events

Migrations from the left column are the multi-quarter projects that stall roadmaps.

Evolutionary Delivery Patterns

• Strangler fig: new capability grows beside the old system behind a router until the old path withers — no big-bang cutover.
• Parallel run: new implementation serves shadow traffic; outputs compared before switching.
• Expand–migrate–contract: schema changes ship in three safe phases, never one destructive step.

All three convert “change” from cliff into ramp.

Interview Framing

When interviewers say “now requirements change — support X,” they are grading your seams. Candidates whose design absorbs X by adding one box behind a named boundary score highest; candidates whose whole diagram must be redrawn reveal fused decisions. One sentence carries the principle: “I kept Y behind a contract precisely so this kind of change stays local.”