System Design

A strong design answer begins by separating functional behavior from non-functional constraints.

• Clarify who uses the system, the write path, the read path, and the most important user action.
• Ask about scale using daily active users, requests per second, data size, latency targets, and availability.
• State assumptions out loud so the interviewer can correct scope before you design the wrong system.

Back-of-the-envelope numbers help you justify storage, cache, queue, and database decisions.

• Convert daily traffic into average and peak QPS, then multiply peak by a safety factor.
• Estimate row or object size, retention period, and replication factor before picking storage.
• Use the estimate to explain why a single database is enough or why partitioning is needed.

Good designs explain how the system behaves during slow dependencies, spikes, and partial failure.

• Use queues for burst smoothing, retries with backoff for temporary failures, and idempotency keys for duplicate writes.
• Prefer graceful degradation when optional features fail, such as recommendations or analytics.
• Name observability signals: latency, error rate, saturation, queue lag, cache hit rate, and database lock wait.

A clear API contract keeps services independent while making the product behavior easy to reason about.

• Define request shape, response shape, pagination, idempotency, and error codes before drawing infrastructure.
• Version public contracts when clients cannot be upgraded at the same time as the backend.
• Use contract tests or schema validation for critical paths so small service changes do not break consumers.