Mastering the System Design Interview: A Five-Step Framework with Three Real-World Case Studies

System design interviews give many engineers a headache—the problems themselves have no standard answer, the requirements are vaguely described, and you only have 45 to 60 minutes. But as senior engineer Haik Simonian points out in his full course, system design interviews don't test your "correct answer"—they test your way of thinking and problem-solving ability. Drawing on his own experience of repeated failures in early job searches, he distilled a reusable five-step framework and demonstrated it using three real systems as case studies: Spotify, Booking.com, and WhatsApp.

Why System Design Interviews Make People Anxious

Unlike behavioral interviews or live coding interviews, system design interviews have no clear inputs and outputs, and no code you can directly run to verify. Haik points out that in coding interviews you know exactly what parameters the function receives, what type it returns, and whether the test cases pass; but system design requirements are often very vague, and there is no single correct answer. What the interviewer really wants to see is how you ask clarifying questions when information is incomplete, lock down scope, and make reasonable technical decisions.

More importantly, now that AI can quickly complete code implementations, companies care more about whether you understand the overall architecture, how components interact, and the trade-offs between solutions. Even for mid-level positions, system design is gradually becoming a required part of the interview process.

The Five Dimensions Interviewers Actually Evaluate

Many candidates only prepare by memorizing architecture diagrams for systems like Spotify and WhatsApp. But Haik emphasizes that interviewers have five dimensions on their scorecard, and memorizing architectures only covers a small part of them.

Communication and Collaboration

Interviewers observe whether you proactively ask clarifying questions and whether you validate assumptions as you go, rather than silently starting to draw diagrams. This reflects how you'll work in a real team—when you receive vague requirements, do you confirm before acting, or do you make assumptions and then rework?

Structured Thinking

When facing an ambiguous problem, can you break it down into clear steps? Strong candidates show an explicit framework of thinking, making it clear what each step is doing and what the next step is so the interviewer can follow along. Conversely, jumping back and forth between different design phases loses points.

Technical Judgment

When you choose a certain database, cache, or message queue, can you explain "why this one"? Is it a choice based on requirements, or because "this is the only one I've used"? This dimension distinguishes engineers with technical judgment from candidates who just apply templates.

Depth of Practice

Two candidates with similar theoretical levels—one has thought about failure modes, scale bottlenecks, and system failure scenarios, the other stays at the theoretical level. Interviewers use this dimension to identify whether you've actually delivered systems in production.

Time Management

A 60-minute interview requires reasonable time allocation. Getting stuck on one part and having no time left to discuss scaling and fault tolerance is a common mistake. Haik suggests aligning with the interviewer early on which direction to focus.

The Five-Step Framework: How to Allocate 60 Minutes

This framework is a repeatable structure that can be used for any whiteboard system design problem. Based on a 60-minute interview:

Step 1: Clarify Requirements (5-10 minutes)

Don't start designing before you understand the scope. You need to clarify functional requirements (what are the core use cases, what is explicitly out of scope) and non-functional requirements (user volume, read/write ratio, latency requirements, acceptable downtime). For example, designing a Spotify-like system can never be fully covered in 60 minutes—the goal is to determine which core use cases to focus on under the interviewer's guidance. At the end of each phase, proactively confirm "is this scope and these requirements reasonable, can I move to the next step"—if you've missed a key point, the interviewer can give you a hint at this checkpoint.

Step 2: Data Model and API Design (15-20 minutes)

For this step, you can choose to do the data model first and then move to high-level architecture, or vice versa. Haik himself usually starts with high-level design, and sometimes also sorts out the data layer first. The key is to define the main entities and their relationships, primary keys, foreign keys, and indexes, and clarify which data needs strong consistency and which can accept eventual consistency. For the API contract, you need to define the main endpoints, pagination, error handling, rate limiting, and versioning strategy.

The reason data model and API design are placed before or parallel to high-level architecture is that they are essentially an explicit definition of the system's "contract." The data model answers "what the system remembers," and the API answers "what the system promises externally." Once both are determined, subsequent storage choices, caching strategies, and scaling solutions must all comply with this contract. In practice, you can use an entity-relationship diagram to sort out core entities, primary keys, foreign keys, indexes, and access patterns, and then use that to determine which reads and writes require strong consistency and which can accept eventual consistency. At the API level, you need to define resources, endpoints, request/response formats, pagination cursors, error code semantics, rate limiting, and versioning strategy. During the interview, don't try to exhaustively enumerate every field. Instead, clearly identify the minimal set of contracts that supports the core use cases, and proactively explain which belong to phase-two extensions. This both controls time and shows the interviewer your sense of boundaries.

Step 3: High-Level Architecture (15-20 minutes)

Almost all systems contain four core components: API servers receiving requests, load balancers distributing traffic, databases persisting data, and an optional cache layer. Start from the user data journey—the frontend initiates a request, it passes through the API gateway and load balancer to the API server, goes through the cache layer to the database, and then returns—walking through the complete read and write paths. When using caching, explain TTL and invalidation mechanisms; between different components, explain the trade-offs among consistency, availability, and performance.

Step 4: Scale, Bottlenecks, and Reliability (5-10 minutes)

Identify single points of failure and propose solutions, discuss degradation mechanisms and redundancy strategies, and explain monitoring and alerting plans (API latency, error rate thresholds, etc.). This part is the clearest signal distinguishing mid-level from senior candidates. Many candidates overlook monitoring and logging, but this is precisely a strong signal to show that you think like a senior engineer.

Step 5: Trade-offs and Scaling (the final few minutes)

Summarize the key decisions, what you prioritized, what you sacrificed, and the reasons behind them. Think about how you would scale if load grew 10x. The goal of the interview is not to design a perfect system—there is no perfect design within 60 minutes—but to demonstrate your thought process under constraints and your potential for scaling.

Case Studies: Key Design Points of Three Systems

Spotify: Storage and Bandwidth Bottlenecks

When designing a music streaming platform, capacity planning reveals a key insight: audio files absolutely dominate storage and bandwidth. With 30 million songs at an average of 3MB each, raw audio data is about 90TB, and with multi-region replicas and duplicate uploads, the actual requirement is 2-3x that. By contrast, song metadata is only about 3GB and user metadata about 500MB, almost negligible in comparison.

On the transmission side, assuming each user plays 10-15 songs per day, CDN and egress bandwidth costs are the core challenge. Architecturally, metadata goes into a relational database, and audio files go into object storage (such as S3), accessed through signed URLs with expiration. When the scale grows to 50 million users and 200 million songs, audio storage reaches about 600TB, requiring strategies such as CDN edge nodes, multi-region load balancing, database read/write separation, and sharding.

Booking.com: Concurrency and Consistency

The core challenge of a hotel booking system is preventing double bookings. Capacity estimation shows this is an extremely read-heavy system: about 1000 QPS of read requests corresponds to only 17 TPS of write requests. But the correctness of write operations is crucial—when two users book the last room at the same time, a simple "check first, then write" will lead to double booking.

The solution is the default Read Committed isolation level combined with a SELECT FOR UPDATE row lock, locking the inventory row before checking and writing. Compared with the Serializable isolation level, row locks allow operations on different rows to execute in parallel, providing better scalability in high-TPS scenarios. For search scenarios, Elasticsearch is introduced to handle full-text search and geographic filtering, maintaining eventual consistency with PostgreSQL through CDC (change data capture)—PostgreSQL always remains the single source of truth, and Elasticsearch only serves to accelerate search.

The reason the combination of Read Committed and SELECT FOR UPDATE can prevent double booking is that row-level locks bind the two actions of "checking inventory" and "decrementing inventory" into one atomic critical section. If two concurrent transactions try to modify the same inventory row, the later one is blocked until the former commits or rolls back, so it is impossible for both to see "one room left" and both write. In contrast, Serializable guarantees serializability through stricter conflict detection or range locks, at the cost of a higher conflict rollback rate under high concurrency, making it prone to becoming a bottleneck in booking scenarios with dozens to hundreds of write transactions per second. Optimistic locking (version numbers or CAS), while avoiding blocking, leads to many retries on highly contended hot rows such as the "last room." Therefore, real systems often mix approaches based on the degree of contention: optimistic for low conflict, pessimistic row locks for high conflict.

WhatsApp: Stateful Connections and Extreme Scale

What makes instant messaging systems unique is the need to maintain stateful long-lived connections. At a scale of 1 billion registered users and 500 million daily active users, the system processes 10 billion messages per day, with peaks reaching 350,000-500,000 writes per second. On the storage side, that's about 10TB per day and 3.6PB per year of writes.

For the communication protocol, WebSocket is the inevitable choice—polling wastes bandwidth and has high latency, and long polling constantly establishes and drops connections. WebSocket maintains a persistent bidirectional channel between the client and the chat server, combined with Redis to cache user online status and connection routing. Offline messages go into an inbox, and users pull them when they come online. Group messages use Redis PubSub to push in parallel to the chat servers where each online user is located. Media files are uploaded directly to object storage via signed URLs, and the chat servers are only responsible for routing the messages themselves, offloading bandwidth pressure to the CDN and blob storage.

For database choice, message storage uses Cassandra or DynamoDB to handle hundreds of thousands of writes per second, while user and group metadata go into PostgreSQL. For sharding strategy, sharding by user ID ensures that a single user's messages are in the same shard, but it creates hotspots; sharding by message ID distributes evenly, but queries require crossing shards. A practical compromise is to shard by user ID and do dual-write message replication—a copy of each user's conversation is also written to the other party's shard, at the cost of doubling writes in exchange for extremely fast read performance.

The fundamental constraint that stateful long-lived connections impose on system design is that every connection must be bound to a specific chat server, and the metadata of that connection (user ID, device ID, server address, last active time) must be queryable in real time by all nodes that need to route messages. This means the state itself becomes a first-class citizen that must be distributed, replicated, and fault-tolerant. A common engineering trade-off is to centrally write connection state into low-latency storage such as Redis, which the routing layer queries and then forwards; at the same time, use consistent hashing or sharding rules based on user ID to pin connections to a group of servers, avoiding full broadcast. You also need to consider connection migration when a server goes down: clients need to reconnect automatically, and during the brief window, messages should go into an offline inbox rather than be dropped. It is precisely these additional designs around connection lifecycle, routing tables, and failover that make instant messaging significantly more complex architecturally than ordinary stateless web services.

Common Mistakes to Avoid in Interviews

Based on his own experience, Haik summarized several high-frequency mistakes. First, starting to design without clarifying—this is the most serious red flag. Second, falling into the extremes of silence or talking too much—either silently drawing diagrams without communicating, or talking endlessly without giving the interviewer room to participate. The right approach is to treat the interviewer as a colleague and confirm direction after each major decision. Third, making choices without explaining why—even if SQL is the obvious choice for a payment system, you still need to explain why not NoSQL and the trade-offs between the two. Fourth, failing to proactively check in at each stage—if you finish the high-level design and go straight to the next step without confirming, you may miss points the interviewer expected you to cover.

The Divide Between Senior Engineers and Mid-Level Developers

Haik summarizes this difference with a pyramid: the bottom layer is planning and blueprint design—understanding requirements, estimating capacity, and choosing architecture, which is the most mentally demanding part. The middle layer is technology stack selection—which specific database, caching strategy, and storage solution to use. The top layer is coding implementation—precisely the part that requires the least mental effort.

This explains a reality: if coding is the only thing you're good at, AI models can do it faster, better, and cheaper. Many mid-level developers fall into the "inverted" development approach—starting to write code directly without planning and technology selection. But engineers who learn to think through the problem before acting will never lack opportunities, because companies always need people who can understand requirements from the user's perspective and turn vague ideas into reality.

One-line Summary

Using a five-step framework and the three case studies of Spotify, Booking, and WhatsApp to break down the evaluation dimensions and winning approach for system design interviews.

Paragraph Summary

System design interviews have no standard answer; they test a candidate's ability to ask clarifying questions, lock down scope, and make reasonable technical decisions when information is incomplete. Haik Simonian's five-step framework splits 60 minutes into clarifying requirements, data and API design, high-level architecture, scale and reliability, and trade-offs and scaling, corresponding to five evaluation dimensions: communication and collaboration, structured thinking, technical judgment, depth of practice, and time management. The three case studies each reveal different core tensions: Spotify's audio storage and bandwidth far exceed metadata, requiring object storage and CDN; Booking.com must use Read Committed plus row locks to prevent double booking; and WhatsApp must handle stateful long-lived connections and hundreds of thousands of writes per second. The article concludes by emphasizing that planning and blueprint design are the real divide between senior engineers and mid-level developers.