A system design interview gives you one broad prompt and less than an hour to turn it into a design you can defend out loud. This plan spreads preparation over four weeks at about 8 to 10 hours a week, for someone who already works as a software engineer. Spend the first two weeks learning seven core concepts, then run timed designs on prompts you have not seen and review each run against what interviewers score. You stop when two timed runs in a row pass the readiness check.
With fewer hours, keep the order and stretch the weeks.
What interviewers assess
Meta's guide to its software engineering interview (dated October 6, 2022) says the design interview is 45 minutes long, "almost never" involves coding, and usually ends with five minutes for your questions. That leaves about 40 minutes for the design itself. Meta says the interview assesses "the candidate's ability to solve a non-trivial engineering design problem." Its tips ask you to find "the interesting and hard problems to focus the discussion on", to explore the tradeoffs and make reasoned decisions about them, and to drive the discussion yourself.
Amazon's SDE II interview prep page describes a loop of four 55-minute interviews and tells you to "expect at least one question on software systems design." The online assessment before the loop also includes 20 minutes of system design scenarios. The page's question tips tell you to treat the interviewer as a customer, note your assumptions, ask what twice or ten times the growth would do to your design, and consider "bottlenecks, failure points, redundancy, and log access." Amazon says it looks for "broad comprehension of system design and expertise in one area", and that if you are asked about an unfamiliar topic you can say so and suggest a familiar one.
Both pages ask you to narrow the prompt with questions and to compare options before you choose one. Amazon also asks you to state your assumptions and to test the design against growth and failure. You build those habits by designing out loud against a clock, so that is where most of the four weeks go.
The four weeks
| Week | Work | Done when |
|---|---|---|
| 1 | Estimation, data storage, caching and partitioning. One untimed design of a URL shortener using only these four. | For each concept, you can name the number or access pattern that would make you use it. |
| 2 | Asynchronous work and idempotency, consistency and failure handling. Two untimed designs. | Each design names one retry rule, one timeout and one consistency choice. |
| 3 | Three timed 40-minute designs on new prompts, each reviewed the same day. | Every review lists the decisions you made and the ones you skipped. |
| 4 | Three more timed designs, one of them in the area you know best, then the readiness check. | You meet the readiness conditions on two runs in a row. |
Concepts to learn, in order
The order follows the design. Estimation comes first because its numbers tell you which of the other six you need.
Estimation
Turn the requirements into requests per second, storage per year and peak load. Do the arithmetic out loud, then say which decision the number changes. If it changes nothing, move on quickly.
Data storage
Choose storage from how the data is read. When nearly every read is by one key, a key-value store fits. Amazon built Dynamo with a "simple primary-key only interface" because services such as shopping carts and session management "only store and retrieve data by primary key and do not require the complex querying and management functionality offered by an RDBMS" (Dynamo paper, SOSP 2007). When you need joins across records or a transaction that spans several rows, start from a relational database and explain how you will scale it. Large files such as photos and videos go in blob storage, and the database keeps their metadata and a pointer to each file. Keep every record on more than one machine, so one failed machine does not take the only copy with it, and reads can move to another copy. That is why storage estimates multiply by the number of copies.
Caching
A cache helps when reads far outnumber writes and slightly old data is acceptable. Learn what happens when the cache is empty. The AWS Builders' Library calls it the "thundering herd" when many clients ask for the same uncached item at once, and Amazon's fix is request coalescing, so "only one pending request is out for uncached resources" (Caching challenges and strategies). The same article says that what to serve when the service behind the cache fails depends on "when it is better for clients to see stale data versus errors." Be ready to make that call for your own design. For static files and media, a CDN is a cache close to users, so those requests are answered near the user and your servers see only the cache misses.
Partitioning
When one machine cannot hold the data or keep up with the writes, split the data by a key. Pick the key from the most common read, then check whether one key could get far more traffic than the rest. Learn consistent hashing, which Dynamo uses to place keys on nodes. The same paper notes that with it, "departure or arrival of a node only affects its immediate neighbors and other nodes remain unaffected."
Once data lives on many machines, a single counter for new IDs becomes a bottleneck. Two workable answers are to give each server its own block of IDs to hand out, or to generate random IDs long enough that a collision is unlikely and check for one on write. A URL shortener turns on this choice.
Asynchronous work and idempotency
Put slow work behind a queue when the user does not need to wait for it. Anything that can be retried must be safe to repeat. Amazon describes an idempotent operation as "one where a request can be retransmitted or retried with no additional side effects", and its preferred way to get one is "a unique caller-provided client request identifier" in the API contract (Making retries safe with idempotent APIs). In a payment or order design, say where that identifier is stored and how long you keep it.
Fan-out is a decision about when work happens. A news feed can copy each new post into every follower's feed when it is written, which makes reads fast and writes heavy for accounts with many followers. It can also build the feed when a follower opens it, which makes writes cheap and reads slower. You can mix the two, and the interviewer will ask where you draw the line. A mailing list with many recipients is the same problem.
Consistency
Eric Brewer wrote in 2012 that "partitions are rare", so a system can offer consistency and availability most of the time, but needs an explicit strategy "when partitions are present or perceived" (CAP Twelve Years Later). In an interview, that means saying for each operation what happens while part of the system is cut off. Two buyers must not both get the last seat. A like count can be briefly wrong. For the seat, learn two mechanisms. A conditional write marks the seat sold only if it is still free, so the second buyer's write fails. A hold with an expiry reserves the seat while the buyer pays and releases it if payment does not finish in time.
Failure handling
Keep application servers stateless and put a load balancer in front of them. Any server can then take any request, you scale by adding servers, and the load balancer stops sending traffic to a server that fails its health checks.
Amazon's practice is to "set a timeout on any remote call" and to add jitter to retries, which it defines as "a random amount of time before making or retrying a request", so clients do not all retry at the same moment (Timeouts, retries and backoff with jitter).
Tail latency matters as soon as one request touches many servers. In The Tail at Scale (Communications of the ACM, February 2013), Dean and Barroso take servers that usually respond in 10 ms but take one second at the 99th percentile. A request that waits on 100 of them is slow 63% of the time, because 1 - 0.99^100 = 0.634. If your design fans one request out to many services, say how you bound that wait.
Running a design in 40 minutes
Practice with a fixed time budget so you finish the design and still reach the part the interviewer cares most about. CramHQ suggests this split for a 40-minute run. For a longer slot, stretch each step in proportion.
| Minutes | Step | What you have at the end |
|---|---|---|
| 0-5 | Requirements and scope | The features in scope, the ones you are leaving out, and the scale you are designing for |
| 5-10 | Estimate | Peak requests per second and storage per year |
| 10-15 | API and data model | The main calls and records, and the key each record is read by |
| 15-25 | High-level design | Every request path drawn end to end |
| 25-35 | Deep dive | The hardest problem in this prompt, with two options compared and one chosen |
| 35-40 | Growth and failure | What fails first, and how an operator would notice |
Name the hard problem by minute 15, ten minutes before the deep dive starts. If the interviewer cares more about something else, that gives them time to steer you there.
A worked estimate
Meta's guide uses "How would you architect the backend for a messaging system?" as its example prompt. The questions it suggests asking first include how many people use it, how many messages are sent, the latency from sender to receiver, how messages are stored, and whether to push new messages to clients or let them pull. Suppose the interviewer answers with 50 million daily active users who each send 40 messages a day, at about 200 bytes per message including metadata. These figures are practice assumptions.
- Messages per day: 50,000,000 × 40 = 2,000,000,000.
- Average writes per second: 2,000,000,000 ÷ 86,400 ≈ 23,000.
- Peak, assuming three times the average: about 70,000 writes per second.
- Storage per day: 2,000,000,000 × 200 bytes = 400 GB.
- Storage per year: 400 GB × 365 = 146 TB, or about 440 TB with three copies of each message.
At about 70,000 writes a second and more than 400 TB a year once replicated, the messages have to be spread across many machines from the start, so the next decision is the partition key. Partitioning by conversation ID keeps each conversation's messages together, and opening a chat reads one partition in order. The interviewer will probe a very large group conversation, which puts all of its traffic on one partition. If the product has group chats with thousands of active members, say how you would split those conversations further or handle them on a separate path.
The push or pull question follows. If 10 million of those users have the app open and each client polls every 5 seconds, that is 10,000,000 ÷ 5 = 2,000,000 requests a second, and most of them come back empty. Keeping one open connection per active client and pushing messages over it removes that load. The cost is a connection tier you have to scale and recover when a server holding connections fails.
A weak answer computes the same numbers and then draws a single database anyway, or picks a partition key without saying which read it serves.
Timed practice
Weeks 3 and 4 are timed runs. Set a 40-minute timer, talk out loud, and draw on a whiteboard or a drawing tool. Do not look anything up during the run. When you do not know something, write it on the board and keep going.
Choose prompts so each one leans on a different concept.
| Prompt | What decides the design | Concepts it tests |
|---|---|---|
| URL shortener | Reads far outnumber writes | Caching, key-value storage, ID generation |
| Messaging backend | Write volume and delivery to online users | Partitioning, push or pull |
| Ticket sales for a popular event | Many buyers want the same seat | Consistency, conditional writes and seat holds |
| Payment checkout | A charge retried after a failed network call | Idempotency, asynchronous work |
| News feed | One post shown to many followers | Fan-out, caching |
| Email server, Meta's own product-design example | Mailing lists with many recipients | Asynchronous work, fan-out |
Make one week-4 run a system close to your own work, and after the timer stops, spend another hour on its hardest part. Amazon says it wants expertise in one area, and Meta says it aims to hold the conversation in "an area slightly familiar to you". Meta also suggests reviewing systems you have already designed and asking what you would change if you built them again.
Reviewing a run
As soon as the timer stops, write a decision log with one line per decision. Each line says what you chose, what you compared it with, and the number or requirement that settled it. Then take Amazon's growth question to your own design. At twice and at ten times the load, name the first component that breaks and what you would change.
Check three more things in every review. Did you state your assumptions out loud? Did you compare two options for the hard problem before choosing? Did you cover failure, and how an operator would see it?
Everything you wrote on the board goes back to the matching concept from weeks 1 and 2, and its source. If the same concept appears in two logs, give it an hour before your next run. Only then read a reference solution, and note where its choices differ from yours and why.
Knowing when you are ready
CramHQ's rule of thumb is that you are ready when two timed runs in a row, on prompts you have not practiced, meet all four of these conditions.
- You finish all six steps inside 40 minutes.
- Your estimate changes at least one decision, and you say which one.
- You can answer the ten-times-growth question without redrawing the design.
- Your decision log has no concept you had to look up afterwards.
If a run misses one condition, work on that condition and run again. Take readiness prompts from outside the practice list. Meta suggests designing a high-scale system you already use every day from the ground up, and its guide also mentions a client-server API for a rich document editor.
CramHQ's free system design assessment takes about 15 minutes and needs no credit card. It asks system design scenario questions and then shows which design decision areas are your weakest, which helps you choose prompts for week 3. The Pass Plan costs USD 49.99 once for 12 months of access and adds targeted repair work, 16 Decision Drills on parts of the interview such as capacity estimation and partitioning, and a Readiness Exam.