Fundamentals

A design is incomplete if it only describes the happy path. Ask what happens when a dependency is slow, a request is retried, a node fails, or traffic exceeds the estimate. Identify the user-visible behavior and the signal that would reveal the problem.

In an interview, communicate continuously: summarize the current model, state the next question, and reserve time to explain failure modes and trade-offs.

Write each requirement as an operation plus a measurable quality goal. Then identify the few requirements that dominate the architecture. A 100 ms target for every write may force a different design than a 30-second freshness allowance for an asynchronous feed.

When targets conflict, surface the conflict and ask which user impact matters most.

Track p50 to understand the typical request and p95/p99 to see the slow tail. Tail latency matters especially when one request fans out to many dependencies: the chance that at least one branch is slow rises with the number of branches.

Compare percentiles for the same operation and traffic conditions, and set objectives that match the user journey.

Check units at every step: requests/day ÷ seconds/day becomes requests/second; bytes/request × requests/second becomes bytes/second. Round to one or two significant digits and avoid false precision.

An estimate is a conversation tool. Use it to decide whether one machine, a cache, or horizontal scaling deserves further analysis.

An added machine can fail independently, and a network call can time out even if the remote service eventually succeeds. Scale-out designs need timeouts, bounded retries, health checks, and ways to isolate overloaded components.

Capacity and reliability are linked: extra instances help only when requests can be redistributed and shared state remains available.

Define availability around user-visible operations and aggregate it across the complete path. Use the error budget to make explicit whether a release, migration, or new feature is worth its reliability risk. A dependency's uptime does not automatically equal the application's uptime.

Design redundancy for named failure modes, then verify failover and recovery in practice.