A framework for system design interviews

The easiest way to sabotage a system design interview is to never deliver a working system. Candidates often call this a time management problem, but the deeper issue is usually focus. They spend too long on generic calculations, list every feature the product could have, or dive into sharding before the interviewer has seen a coherent request flow.

A framework is not a script. It is a recovery mechanism. When you get nervous, you know what comes next. When the interviewer interrupts, you can return to the structure. When a detail is tempting, you can ask whether it helps the design.

The goal is simple: build up a system linearly. Clarify requirements, name the entities, define the interface, draw a working high-level design, then use the remaining time to harden the parts that matter most.

Start with what users or clients need to do. These are your "users should be able to" statements, and they should map directly to the system you are about to design.

For a Twitter-like system: users can post tweets, follow other users, and view a home feed. For a cache: clients can insert items, read items, and set expirations. For Ticketmaster: users can browse events, reserve seats, and complete payment.

Keep this list short. Many real products have hundreds of features, but your interview design should usually focus on the top three flows. A long feature list hurts you because every requirement becomes something your design is expected to satisfy.

Ask targeted questions as if you were talking to a product manager: "Should users be able to edit tweets?" "Do we need direct messages?" "Should seat reservations expire automatically?" Then prioritize. A useful phrase is: "I am going to focus on these three flows unless you want me to prioritize something else." That makes scope explicit and gives the interviewer a clean chance to redirect.

Non-functional requirements are where the architecture gets shaped. They describe system qualities: scale, latency, availability, consistency, durability, security, abuse resistance, compliance, cost, and operational complexity.

Avoid empty requirements like "it should scale" or "it should be low latency." Nearly every system should scale and respond quickly. Make the requirement specific to the prompt: feeds should render in under 200 ms, search should return in under 500 ms, seat reservations must prevent double booking, uploads can complete asynchronously, or analytics can be delayed by minutes.

A quick checklist helps. Should the system prioritize consistency or availability? Is the traffic read-heavy, write-heavy, bursty, or predictable? Is data loss tolerable? Are there regulatory constraints? Does the system run on constrained devices? Are there high-risk abuse cases? What has to recover automatically when a dependency fails?

Pick the three to five non-functional requirements that matter most. You are not trying to prove that you know every quality attribute. You are trying to identify what the design should optimize for.

Many candidates have been told to do back-of-the-envelope math early. That advice is only useful when the math changes the design. If you calculate daily active users, QPS, and storage just to conclude "this is large," the interviewer learned very little.

A better default is to say: "I will skip detailed estimates upfront and do the math when it affects a design choice." Then actually do that math when it matters.

For example, if you are designing trending topics, estimating the number of active topics can influence whether a single heap is enough or whether you need partitioned aggregation. If you are designing image storage, estimating upload volume and file size affects object storage, CDN strategy, and lifecycle policies. If you are designing a chat system, estimating concurrent connections affects gateway fanout and load balancing.

You should still be comfortable with quick estimates. The point is not to avoid numbers. The point is to use numbers as decision tools, not as ritual.

Before drawing architecture, name the core things the system stores and exchanges. This gives you a shared vocabulary with the interviewer and keeps the design grounded.

URL shortener: user, short link, long URL, click event. Ticketing: event, venue, seat, reservation, order, payment. Feed: user, post, follow edge, feed item. Web crawler: URL, crawl job, page, host, content fingerprint.

This is not a full schema design. Do not spend five minutes listing every column on a user table. You do not know enough yet, and most fields are obvious. Instead, identify the nouns that matter for the requirements. As your high-level design becomes clearer, add the specific fields that influence correctness or scale: reservation status, expiration time, idempotency key, follower ID, created timestamp, shard key, or version number.

Two useful questions: who are the actors in the system, and what resources are necessary to satisfy the functional requirements?

The API is the contract between your system and its users. It turns requirements into operations, exposes missing details, and gives your high-level design a concrete target.

Default to REST for most product-style interviews. Use plural resources and standard HTTP verbs: `POST /v1/tweets`, `GET /v1/tweets/{tweetId}`, `POST /v1/follows`, `GET /v1/feed`. GraphQL is useful when diverse clients need different data shapes. RPC or gRPC is useful for internal service-to-service APIs where action-oriented calls and performance matter. For real-time features, you may also need WebSockets or server-sent events, but design the core API first.

Keep this lightweight: endpoint, key inputs, key output. You do not need a full OpenAPI spec.

Be careful with identity and trust boundaries. The current user should usually come from the auth token, not from a request body. Do not design `POST /follows` with a trusted `followerId` in the body if the server can derive the follower from authentication.

Call out idempotency where it matters. If a user retries reservation creation or payment, what prevents duplicate state? If a webhook is delivered twice, how does the system avoid processing it twice?

For some systems, especially data-processing systems, it helps to list the high-level data flow before drawing boxes. If the prompt is mostly CRUD, skip this step. If the prompt involves pipelines, ingestion, ranking, crawling, indexing, or analytics, this can save time.

For a web crawler: fetch seed URLs, parse HTML, extract links, canonicalize URLs, deduplicate, store content, schedule recrawls. For a search system: ingest documents, parse content, build index, serve queries, rank results, log feedback. For a video pipeline: upload, transcode, generate thumbnails, store metadata, publish playback assets.

This should be a simple sequence, not a full architecture. Its job is to reveal the major stages your high-level design must support.

Now draw the simplest system that satisfies the functional requirements. Start with clients, an API layer, services, storage, and any obvious async work. Build the design endpoint by endpoint or flow by flow.

For `POST /tweets`, show request validation, the write path, storage, and any event publication. For `GET /feed`, show how the feed is assembled and returned. For `POST /reservations`, show how seat availability is checked and state changes. This keeps the diagram connected to the API instead of turning it into a collection of disconnected boxes.

Do not add complexity too early. Caches, queues, search indexes, CDNs, streams, replicas, and sharding are all useful, but every box should earn its place. If you notice that a cache or queue will probably be needed, mark it verbally and keep moving: "Feed reads will likely need caching, but I will first complete the baseline design and come back to read latency in the deep dive."

Narrate state changes as you draw. What database rows are created or updated? What cache entries are read or invalidated? What events are published? What response goes back to the client?

If the interviewer cannot follow a request through your system, you are not ready for deep dives. A complete simple design beats an incomplete advanced design.

Deep dives are where stronger signal shows up. Use the remaining time to harden the design against the non-functional requirements, edge cases, bottlenecks, and interviewer probes.

Choose deep dives that match the prompt. Ticketmaster: reservation consistency, payment idempotency, and high contention during popular sales. Feed: fanout-on-write versus fanout-on-read, ranking, cache invalidation, and celebrity users. File storage: large uploads, metadata consistency, durability, and CDN delivery. Chat: ordering, delivery guarantees, presence, reconnects, and push notifications. Search: indexing latency, ranking, query fanout, and freshness.

A useful transition is: "The basic system is on the board. I think the riskiest part is preventing double booking, so I would go deeper there." That tells the interviewer you can identify the real problem.

Seniority changes how proactive you should be. More junior candidates can expect the interviewer to point at weak spots. More senior candidates should identify them first and lead the conversation. But do not talk over the interviewer. Leave room for questions because they may be looking for specific signals.

Do not end with only a diagram. End by naming the tradeoffs and the failure modes your design accepts.

"This feed design makes reads fast by denormalizing, but writes become more expensive and feed freshness is eventually consistent."

"This reservation design protects seat ownership with transactions, but the database becomes the bottleneck during peak sale windows."

"This upload design moves large files directly to object storage, but metadata and blob state can temporarily disagree, so we need cleanup jobs and reconciliation."

Then name the next improvements: observability, backpressure, rate limiting, regional failover, abuse prevention, retention, migrations, or operational runbooks. Keep it brief. The goal is to show that the design is intentional and that you understand what would break first.

For a 45 to 60 minute interview, use this rough split: 5 minutes for requirements, 2 minutes for entities, 5 minutes for APIs, 0 to 5 minutes for data flow if the prompt needs it, 10 to 15 minutes for high-level design, 15 to 25 minutes for deep dives, and a few minutes for tradeoffs.

If the interviewer pushes you forward, move. If they pull you into a deep dive early, follow them. If you realize you are spending too long on one section, say so and transition: "I want to make sure I deliver the full system, so I will move to the high-level design now and come back to estimates if they affect a decision."

The framework exists to keep you oriented, not to make you rigid. The best candidates use structure while still collaborating with the interviewer.