Trade-offs

📘What it really is

• Every design decision is a trade-off. Architecture is choosing which qualities matter most and accepting the costs.
• Common trade-offs:
• simplicity vs flexibility: a simple design is easier to build and run; a flexible one handles more futures but costs more now (often for futures that never arrive);
• consistency vs availability: in distributed systems, during network problems you may have to choose (Module 94);
• speed of building vs long-term maintainability;
• build vs buy (Module 99): your own payment system (never) vs a gateway; your own auth vs a proven service;
• cost vs performance and availability (Module 68);

• performance vs simplicity: caching makes things faster and adds staleness and complexity (Module 95).

• Make trade-offs explicit: for each important decision, write the options, the qualities each favours, and why you chose. This is an Architecture Decision Record (ADR) (Module 99):

# ADR 003: Use a single PostgreSQL database with a unique constraint to prevent double booking
Status: accepted · Date: 2026-11-01
Context: Two students must never book the same slot (NFR-4). Expected load is modest.
Options: (1) database unique constraint + transaction; (2) distributed lock in Redis; (3) separate booking service with queue.
Decision: (1). Simplest, strongly consistent, enough for 100x today's load.
Consequences: booking writes go to one primary database; revisit if writes exceed ~1,000/second.

• Prefer the simplest design that meets the requirements, with clear points where you'd change it. "You aren't gonna need it" (YAGNI) protects small teams from over-engineering.

• Reversible vs irreversible decisions: move fast on decisions that are easy to undo; think hard about ones that aren't (database choice, data model, public API shapes).