Before finishing a system design interview, check whether you have addressed the following:

Requirements and scale

• Functional requirements and scope are clear.
• Latency, availability, consistency, and durability goals are explicit.
• Average and peak traffic have been estimated.
• Storage, retention, and bandwidth have been considered.

Architecture and data

• The high-level architecture is easy to follow.
• Core APIs and data models are defined.
• Database choice follows from access patterns and correctness requirements.
• Important indexes, partitions, and cache keys are identified.
• Read and write paths are traced end to end.

Scale and reliability

• Likely bottlenecks and hot spots are identified.
• Timeouts, retries, idempotency, and partial failures are addressed.
• Replication and failover behavior are explained.
• Backpressure and overload behavior are defined.
• Backup, RPO, RTO, and recovery requirements are considered where relevant.

Security and operations

• Authentication, authorization, and tenant isolation are addressed.
• Metrics, logs, traces, and actionable alerts are considered.
• Deployment, rollback, and schema compatibility are addressed.
• Cost and operational complexity are acknowledged.

Communication

• Assumptions are stated rather than hidden.
• Every major component has a clear purpose.
• At least two meaningful trade-offs are explained.
• The design is evolved only when a requirement justifies it.

Final reminder: a good system design is not a diagram full of boxes. It is a reasoned explanation of how the system meets its requirements, scales under load, preserves correctness, and behaves when components fail.