Amazon System Design Interview: What the Bar Actually Tests at Each Level

If you're preparing for an Amazon system design interview, you've probably read guides that say "design URL shortener, add a cache, use load balancers." That advice isn't wrong. It's just incomplete. Amazon evaluates system design differently than most companies, and if you don't know how, you'll walk out thinking you nailed it while the interviewer is writing "did not demonstrate operational thinking."

Not Every Amazon Level Gets a System Design Round

The Amazon onsite runs four to five rounds. SDE1 (entry-level) has no distributed design round; you'll get object-oriented design: parking lot, vending machine, library system. Class structure, encapsulation, data modeling. Two things these share: they're nicely bounded, and they won't page you at 3am.

At SDE2, expect one 45-minute system design round. The rest are coding and behavioral. A weak design score is the single hardest result to recover from. Strong coding rarely saves a "no hire" on design.

At SDE3, Amazon's official prep page says to expect at least one design question, and the framing shifts from "design a system" to "own a technical direction." Same format, higher bar.

Each round is evaluated independently. Interviewers submit written feedback before any debrief. Your performance stands or falls on what you produced in those 45 minutes. There is no averaging with a friendly behavioral round.

What Amazon Actually Scores

Amazon's official SDE II prep page names six scoring axes: practicality, accuracy, efficiency, reliability, optimization, scalability. Those words are abstract. In a real 45-minute round they collapse into five observable behaviors, and missing any one of them is usually fatal.

Requirements gathering (practicality, accuracy). Did you ask the right questions before drawing anything? Functional and non-functional requirements (scale, latency, consistency, availability) should be explicitly scoped. Drawing before clarifying signals you don't clarify before building.

High-level design (practicality, scalability). Does your architecture make sense? Are components justified? Can you explain data flow end to end without handwaving?

Component depth (accuracy, efficiency). Can you go deep on one or two components? Schema, API contracts, cache invalidation, queue semantics. Breadth without depth doesn't pass at SDE2+.

Trade-off reasoning (optimization). This is where Amazon diverges from generic prep. They want to hear you name trade-offs before they ask. SQL vs NoSQL, consistency vs availability, event-driven vs synchronous. Not what you chose. Why.

Operational design (reliability). This one surprises candidates the most. Amazon's engineering culture runs on Werner Vogels' line from his 2006 ACM Queue interview: "you build it, you run it." You are personally accountable when this thing catches fire in production. A design without failure modes is a blueprint for a house with no fire exits. Interviewers expect you to explain how the system fails, how you detect it, and how you recover. Concretely: what happens when your retry policy meets a downstream brownout? The AWS Builders' Library on retries shows three retries per layer across five layers amplifies load 243x, a self-inflicted DDoS. The right answer adds jitter, circuit breakers, and a dead letter queue, plus a plan for when the DLQ fills with poison messages that crash your consumer. Skip operations and your design is technically clever but operationally fictional.

How the Bar Shifts by Level

For SDE2, the expectation is that you apply known patterns correctly. Know why you'd use a queue over a synchronous API call, when to denormalize, how a CDN fits a read-heavy system. Handle a well-scoped problem within one service boundary at scale.

For SDE3, the problem is deliberately less defined. You may get "design Amazon's inventory allocation across fulfillment centers." The interviewer expects you to drive scoping, identify unstated constraints (consistency during flash sales, cross-region replication), and design for the 0.01% case. The 2017 S3 outage in us-east-1 is the canonical example: one mistyped command removed more capacity than intended and took down a chunk of the internet for four hours. The fix AWS shipped, partitioning S3 into smaller cells to limit blast radius, is the thinking an SDE3 should bring to the design round, not after the incident. An SDE3 who produces the same design as an SDE2 will not pass.

The shift is roughly: applying patterns correctly versus deciding which patterns the next five teams will live with for four years.

The Ten Questions That Show Up Most

These show up regularly in Amazon design loops, based on public candidate reports on Glassdoor and LeetCode Discuss. Some are Amazon-domain-specific. Others are universal problems Amazon uses because they map to real systems Amazon operates.

Question	Why Amazon Asks It
Design Amazon.com (e-commerce platform)	Tests inventory, ordering, payments, and catalog at real Amazon scale
Design a URL shortener	Classic: hashing, redirect logic, analytics, abuse prevention
Design a notification system	Tests fan-out, delivery guarantees, multi-channel routing
Design a distributed cache	Tests eviction policies, consistency, replication
Design Amazon S3 (object storage)	Tests chunking, metadata separation, replication
Design a recommendation engine	Tests offline/online pipeline, feature freshness
Design a rate limiter	Tests token bucket vs. sliding window, Redis, distributed enforcement
Design a delivery tracking system	Tests state machines, event sourcing, real-time updates
Design Amazon Prime Video's video upload pipeline	Tests async processing, encoding, CDN delivery
Design a search autocomplete system	Tests trie vs. inverted index, prefix search at scale

You don't need memorized answers. Most share the same building blocks: write path, read path, storage, async processing, cache. Understand the patterns well enough to derive a reasonable design under pressure.

How to Run the 45 Minutes

Forty-five minutes sounds like a lot until you realize you need to scope, estimate scale, design the architecture, depth-dive two components, and walk through failure modes before the timer runs out. Most candidates hit minute 42 with no operational story. That's a miss.

Minutes 0-5: Clarify requirements. Ask about scale (users, QPS, data volume), read/write ratio, latency and consistency targets, geographic constraints. Write them down. Reference them later when justifying decisions. Skipping this is the fastest way to spend 35 minutes building the wrong system with great confidence. See clarifying questions in a coding interview for the underlying skill.

Minutes 5-8: Estimate scale. Back-of-envelope math, where assumptions stop being abstract and start picking your architecture. Take the URL shortener: 10M DAU, 5 clicks/user/day. That's 50M reads/day, or 50M / 86,400 ≈ 580 QPS average. Peak isn't 580; the consumer-app rule of thumb is 3-5x average (the Google SRE book uses similar multipliers), so provision for ~2,000-3,000 QPS. Writes are roughly 100x less frequent: ~6 QPS for new short links. Those two numbers decide your design. 580 reads/sec means one Postgres node handles reads with an aggressive cache; 6 writes/sec means no sharding for ingest. Storage at 10M links/day × 500 bytes is 1.8 TB/year, fits on one machine. "Let's shard the database" is the wrong instinct at this scale. Get the numbers first; defend or reject patterns from them.

Minutes 8-20: High-level design. Draw the boxes. Client, load balancer, API servers, database, cache, queue, workers. Explain why each exists. Label your arrows. Keep moving.

Minutes 20-35: Deep dive. Pick one or two components where the real complexity lives and go deep. The interviewer may redirect. Follow them. If they keep asking about the database schema, that's where they want time. Don't defend your original plan.

Minutes 35-42: Failure modes and monitoring. Walk through what happens when your cache goes down (thundering herd against the DB), when a queue backs up (consumer falls behind, latency rises, retries amplify), when your DB primary fails (failover seconds, replication lag, split-brain). Add jittered retries, circuit breakers, a DLQ, and at least one alert metric. Narrating this is the skill at the heart of the round; see technical interview communication for how to do it without sounding rehearsed.

Minutes 42-45: Wrap up. Summarize trade-offs you made and what you'd do with more time.

The Amazon-Specific Wrinkle Nobody Warns You About

Leadership Principles aren't just for behavioral rounds. At Amazon, they're baked into how engineers actually make decisions, which bleeds into system design through the questions your interviewer asks and how trade-offs get framed. There are sixteen of them, counting "Strive to be Earth's Best Employer" and "Success and Scale Bring Broad Responsibility" added in 2021. Older prep guides still say fourteen. They are wrong. You will feel the LPs in the room as the second question after every architectural choice, the one that starts with "and if cost mattered, what would change?"

"Bias for Action" surfaces when you choose between a design you can ship in two weeks and an optimal one that takes six months. Reason about reversible vs architectural commitments out loud. Treating every choice as equally high-stakes is a signal. Not a good one.

"Frugality" surfaces when you over-engineer. If your answer to every bottleneck is "add more servers," expect a follow-up about cost. Could you serve the same read load with half the cache tier? Amazon runs the cloud. They know what instances cost.

"Customer Obsession" shows up as: "what if the customer sees a two-second delay during peak load?" Have a degradation story.

You don't need to name-drop Leadership Principles. Designing as if these values are constraints, because at Amazon they are, produces better answers.

Five Mistakes That Cost Candidates the Round

Designing before clarifying. The first thing you draw should not be a box. It should be a list of requirements. Skip this and you produce beautifully detailed designs for the wrong system.

Ignoring failure modes. A design that only covers the happy path is half a design. No Amazon interviewer lets this slide; it cuts against "you build it, you run it." Elegant diagram, failed dimension.

Going wide instead of deep. Fifteen services in ten minutes followed by defense-of-the-diagram doesn't demonstrate mastery. It demonstrates pattern-matching. Pick two areas and actually know them.

Not narrating trade-offs. Choosing DynamoDB over PostgreSQL is fine. Not explaining why means the interviewer can't tell if you reasoned or guessed. The reasoning matters more than the conclusion.

Ignoring the interviewer's signals. If they keep asking about your database choice, go deeper. If they say "assume the cache is solved," move on. Plowing ahead on your plan signals you don't absorb feedback, particularly costly at Amazon where responsiveness is itself a Leadership Principle.

How to Prepare for the Amazon System Design Interview

For SDE2, four to six weeks of focused prep is realistic if you already have fundamentals.

Weeks one and two: core concepts. Consistent hashing, replication, CAP, cache eviction, message queue semantics. Don't just know vocabulary. Know when to apply each and what the failure mode is.

Weeks three and four: problem practice. Five to eight full problems end to end, timed. Write requirements, scale estimates, the diagram, the failure analysis. If you haven't done this out loud, you haven't practiced. The interview is a spoken explanation, not a written doc. Narrating under pressure is its own skill, and reading articles doesn't develop it.

Weeks five and six: mock interviews. Practice explaining your design to someone who interrupts. SpaceComplexity runs voice-based mock sessions that train the narration skills written practice misses.

For SDE3, add two weeks and focus on ambiguous prompts. Scope problems yourself instead of accepting a clean spec. Design for operations from the start.

For the full loop, see the Amazon software engineer interview guide. For senior expectations, the Amazon senior software engineer interview guide covers how the bar shifts at SDE3. Worked walkthroughs: distributed cache system design and e-commerce system design.