Architecture, Design, and Planning
What this section covers
Design questions test whether you can convert requirements into a defensible structure. Separate functional requirements (what the system does) from non-functional requirements (availability targets, latency, throughput, compliance, cost ceiling). Learn the standard patterns and what each one buys you: layered/N-tier separation, loose coupling via queues, statelessness for horizontal scale, idempotent operations for safe retries, caching for read latency, and redundancy plus health checks for single points of failure. Understand CAP as a partition-time trade-off, not a blanket "pick two" slogan. Planning content adds capacity forecasting, dependency mapping, total cost of ownership, and the difference between a reference architecture (a pattern to adapt) and a blueprint (a near-fixed design).
Traps
- Jumping to a resilient, expensive design when the question says "lowest cost that meets the requirement".
- "Which is the FIRST step?" - almost always requirements/constraint discovery, not implementation.
- Assuming active-active is required when active-passive satisfies the stated RTO.
- Ignoring operational burden: a design no one can run is a wrong answer.
Worked example
Availability math is a fast discriminator. 99.9% over a 30-day month (43,200 minutes) permits about 43 minutes of downtime; 99.99% permits about 4.3 minutes. Two independent components in series multiply: 0.999 × 0.999 ≈ 0.998, which is worse than either alone - so adding a serial dependency costs availability. Rule of thumb: serial dependencies multiply, redundant parallel paths improve, and every added component is a new failure domain.