System Design Interview Checklist

This checklist follows the phases of a system design interview. Use it during practice to verify that each phase produced its output, and during the interview as a reference for what to cover. The reasoning behind each phase is in the system design interview framework.

flowchart LR
    P["Before"] --> R["Requirements"]
    R --> E["Estimation"]
    E --> D["Design"]
    D --> K["Deep dive"]
    K --> W["Wrap-up"]

Before the interview

• Know the format and duration; confirm the drawing tool works.
• Review the numbers cheat sheet: latency values, seconds per day, availability nines.
• Review the technology choice guide.
• Prepare a default order: requirements, estimation, design, deep dive, wrap-up.
• Practice explaining components aloud, not only drawing them.

Requirements

• Restate the problem in one sentence.
• List functional requirements as short verb phrases.
• Prioritize them; select the core two to four.
• State non-goals (out of scope).
• Ask about users and scale: daily active users, growth.
• Ask about the read/write ratio and the most frequent operations.
• Set non-functional targets: latency (percentile), availability, consistency, durability.
• Ask about constraints: geography, data retention, compliance, existing systems.
• Confirm the list with the interviewer.

See functional and non-functional requirements.

Estimation

• Convert users to requests per day, then to average QPS (divide by 86,400).
• State the peak factor and compute peak QPS.
• Split into read QPS and write QPS.
• Compute storage: records x size x retention x replication.
• Compute bandwidth for ingress and egress.
• Compute cache size if a cache is planned.
• State the design consequence: single node or partitioned, cache needed, CDN needed.
• Write units next to every number.

See back-of-envelope estimation.

High-level design

• Define the API: endpoints, parameters, responses, authentication.
• Define the data model: entities, keys, relationships, access patterns.
• Choose storage per data type and give the reason.
• Draw clients, load balancer, stateless services, storage, cache, queues, workers.
• Trace the write path end to end.
• Trace the read path end to end.
• Identify synchronous versus asynchronous steps.
• Confirm every functional requirement is served by the design.
• Note where each component scales: replicas, partitions.

Deep dive

• Name the two or three hardest components and confirm the choice with the interviewer.
• For each: state the sub-problem and why it is hard at the estimated scale.
• Present at least two alternatives.
• Compare them against the requirements and estimates.
• Decide, and state what the decision gives up.
• Describe behavior on failure: node crash, network partition, slow dependency.
• Address correctness: consistency guarantees, ordering, duplicates, idempotency.
• Address skew: hot keys, hot partitions, popular items.
• Address caching: what is cached, eviction, invalidation, staleness.

Typical deep-dive prompts and where to look:

Wrap-up

• Identify single points of failure and their mitigations.
• Identify the first bottleneck at 10 times the estimated load.
• Describe monitoring: key metrics, alerts, logs, traces (see observability).
• Describe failure recovery and data backup.
• Mention security: authentication, authorization, encryption, abuse protection.
• Mention multi-region or disaster recovery if availability targets require it.
• List possible extensions and what would change in the design.
• Summarize the main trade-offs made, in a few sentences.

Time checkpoints for a 45-minute round

If a checkpoint is missed, shorten the next phase instead of skipping it: reduce estimation to the two numbers that decide the design, or reduce the number of deep dives.

Throughout the interview

• Think aloud; state assumptions as they are made.
• Keep the requirements list, numbers, and diagram visible.
• Announce transitions between phases.
• Check with the interviewer at phase boundaries.
• Give an alternative and a cost for each major decision.
• Track time against the budget: about 5 minutes requirements, 3 to 5 minutes estimation, 10 to 15 minutes design, 15 to 20 minutes deep dive.

Common failure modes are listed in interview communication and common mistakes.

Interview questions

• What is the minimum output of the requirements phase? A prioritized functional list, non-functional targets, and stated non-goals. Without them, later choices cannot be justified.
• When can estimation be skipped? It should not be skipped. If time is short, compute only the numbers that decide a structural choice, such as peak QPS and total storage.
• What separates a good deep dive from a component list? A deep dive explains the mechanism, compares alternatives against the requirements, states the trade-off, and covers failure behavior.
• What should the final minutes contain? Single points of failure, the first bottleneck at higher load, monitoring, and extensions, so that the risks are stated before the interviewer raises them.