System Design Interviews

Introduction

System Design Architecture Interviews at Amazon evaluate whether candidates can design production systems under real constraints — scale, cost, failure modes, and operability — while demonstrating Leadership Principles. Unlike pure algorithm interviews, the loop probes end-to-end architecture: API design, data model, caching, async processing, monitoring, and how the design fails gracefully when dependencies break.

Real production story

An Amazon bar-raiser loop asked: "Design a notification system for Amazon retail." The candidate proposed Kafka, 50 microservices, and multi-region active-active in 35 minutes. The bar-raiser asked: "What's your partition key for order events during Prime Day?" Silence. Then: "Who gets paged at 3 a.m. when notification delivery lag exceeds 5 minutes?" The candidate had no on-call model.

The hire decision: No. Technical breadth without operational depth fails Amazon's bar. The candidate who passed the next week started with customer stories (order shipped, delivery delayed), worked backward, sized QPS for Prime Day 10×, chose partition keys explicitly, defined DLQ and idempotency, and described the CloudWatch alarm that pages on-call — same problem, different framing.

Business problem

Business pressure: Amazon hires engineers who design systems that run in production at Prime Day scale — interviews must predict on-call success, not whiteboard aesthetics.

• Revenue at risk: Bad architecture hires become senior engineers owning checkout paths — mistakes cost GMV.
• Engineering velocity: Bar-raiser program ensures consistent bar across orgs — system design signal must be calibrated.
• Compliance / trust: Customer Obsession LP requires designs start from customer experience — not technology choices.

Architecture overview

Amazon system design interview structure: (1) clarify functional + non-functional requirements, (2) estimate scale (QPS, storage, bandwidth), (3) high-level components and data flow, (4) deep dive on 1–2 critical components (usually data model + hot path), (5) failure modes and mitigations, (6) observability and on-call. Leadership Principles woven throughout — Customer Obsession, Dive Deep, Bias for Action, Insist on Highest Standards.

• Definition: End-to-end architecture interview assessing production readiness at Amazon scale.
• When to adopt: SDE II+ loops, Principal Engineer screens, internal promotion to senior.
• When to defer: New grad loops — narrower scope, focus on fundamentals.
• Operability: Candidates must describe alarms, dashboards, and runbook triggers — not optional.

Architecture motivation

Why architects care: Amazon system design interviews test the full architecture lifecycle: requirements → high-level design → deep dive on critical path → failure modes → operability. Skipping any stage fails the bar.

• Force: Systems must scale 10× on Prime Day; fail gracefully; be operable by 3-person on-call rotation.
• Constraint: 45–60 minute interview — prioritize critical path depth over covering every component.
• Outcome: Structured answer: requirements, estimation, HLD, deep dive, bottlenecks, monitoring.

Internal architecture

Amazon system design interview flow:

Minute 0–5:   Requirements + NFRs (latency, availability, durability)
Minute 5–10:  Back-of-envelope (QPS, storage, Prime Day 10×)
Minute 10–20: HLD — clients, API, services, stores, async
Minute 20–35: Deep dive — partition key, consistency, idempotency
Minute 35–45: Failure modes — dependency down, hot partition, retry storm
Minute 45–50: Observability — metrics, alarms, on-call trigger
Minute 50–55: Cost sanity check + LP reflection

Data flow

Notification system deep dive example — what bar-raiser probes after HLD:

• Write path: event → SQS → worker → idempotent send via provider API → dedupe table.
• Read path: user preferences cached in ElastiCache; TTL + invalidation on update.
• Async path: DLQ for failed sends; replay with exponential backoff; max retry cap.

// Partition key design — Amazon interview deep dive
// BAD: partition key = notification_id (random) → hot partitions unlikely but no locality
// GOOD: partition key = customer_id → even spread for retail customer base
// PRIME DAY: celebrity product launch → shard fan-out for marketing blast notifications

interface NotificationEvent {
  customerId: string;  // DynamoDB PK
  eventSk: string;     // sort key: timestamp#type
  idempotencyKey: string;
}

// On-call alarm
// CloudWatch: ApproximateAgeOfOldestMessage > 300s on notification-queue → page

System design diagram

Two diagrams show the System Design Interviews topology and the primary request/event path used in production at scale.

Production code example

Interview answer template — notification system skeleton bar-raisers expect:

/*
REQUIREMENTS: order/delivery/marketing notifications; prefs; 99.9% delivery
SCALE: 50M customers; 10M notifications/day; Prime Day 10× burst

HLD: API GW → NotificationService → SQS → Workers → SNS/SES/Pinpoint
     Preferences: DynamoDB (customerId PK)
     Idempotency: DynamoDB dedupe (idempotencyKey, TTL 7d)

DEEP DIVE: customerId partition key; at-least-once + idempotent worker
FAILURES: provider down → circuit breaker + DLQ; queue age alarm
OBS: CloudWatch queue age, send success rate, p99 latency; page on age > 5min
*/

Enterprise case study

Amazon bar-raiser calibration — notification design: Candidates who start with customer journeys and end with on-call alarms pass at 3× rate vs technology-first candidates in calibration data.

• Before: inconsistent bar — some interviewers rewarded microservice count.
• Decision: Structured rubric: estimation, partition key, failure modes, observability required for " hire".
• After: Bar-raiser shadow program; false positive senior hires on architecture reduced in pilot orgs.

Trade-offs

• Consistency vs availability: notifications often AP — at-least-once with idempotency beats strong consistency blocking checkout.
• Push vs pull: push scales with fan-out cost; pull simpler for mobile but battery impact.
• Microservices vs modular monolith: Amazon accepts either if boundaries and operability clear — microservices without ownership model fails.

Security considerations

Security is architectural: Amazon loops expect PII handling, auth on APIs, and rate limiting on notification triggers.

• Identity: customer can only read/update own notification preferences — authZ on every API.
• Data: phone/email encrypted; minimize retention; GDPR delete propagation.
• Abuse: rate limit notification triggers per customer to prevent spam vector.

Scalability analysis

Scale dimensions: Bar-raiser always probes Prime Day 10× — candidates must identify bottleneck before interviewer asks.

• Partition keys: DynamoDB/Kafka key choice determines hot spot survival.
• Async buffering: queue depth absorbs spikes — size for peak enqueue rate.
• Regional: when multi-region required vs expensive over-engineering.

Failure scenarios

What breaks: SMS provider down; queue backlog; duplicate notifications without idempotency; on-call never paged.

• Provider outage: circuit breaker + fallback channel (email); DLQ replay.
• Queue backlog: autoscale workers on ApproximateNumberOfMessagesVisible.
• Duplicate sends: idempotency key in dedupe table with TTL.

Staff engineer insights

• Work backward from customer story — Amazon LP Customer Obsession is not cosmetic in system design.
• Volunteer the partition key and hot spot analysis before the bar-raiser asks — signals seniority.
• End with "who gets paged and on what alarm" — operability closes the loop.

Interview questions

Architecture review questions

• Are quality attributes (latency, availability, consistency) explicit with SLOs for System Design Architecture Interviews?
• Is the failure/degraded mode documented — including what happens when dependencies are down?
• Are boundaries and ownership clear on an architecture diagram a new engineer understands in 10 minutes?
• Is there an ADR capturing alternatives considered and why they were rejected?
• Can this design scale 10× on traffic and 3× on engineering headcount without a rewrite?
• Security: authn/authz, encryption, and blast radius reviewed at every external interface?

Summary

System Design Architecture Interviews at Amazon test production-ready thinking under scale — Customer Obsession framing, Prime Day estimation, partition key deep dives, failure modes, and on-call alarms. Technology choices matter less than operability and trade-off clarity.