System Design Interview Questions 2026 — New AI-Era Patterns

Seventy percent of engineers who fail system design interviews aren't failing on knowledge. They're failing on reasoning — they know the components but can't defend why they chose them. The interviewer at Razorpay or Stripe doesn't care that you know what Kafka is. They care whether you understand when Kafka is the wrong answer.

This is a guide built from real questions asked at Razorpay, Flipkart, Swiggy, Stripe, and Coupang — with the frameworks interviewers actually use to score you, the mistakes that eliminate candidates at each company, and the level-specific bar you need to clear.

---

System Design Interview Questions: What Interviewers Actually Grade

Most system design prep focuses on component recall: "Do you know what a message queue does? Can you describe consistent hashing?" That knowledge is table stakes. It's the floor, not the ceiling.

Across rubrics used at product companies, the scoring weights break down roughly like this:

| Dimension | Weight | What they're checking | |---|---|---| | Judgment | ~32% | Did you make the right trade-off for this specific problem? | | Depth | ~30% | Can you go 3 levels deep on the hardest component? | | Operational maturity | ~20% | Did you think about monitoring, failure recovery, and rollback? | | Communication | ~18% | Can you think out loud and drive the discussion? |

Judgment and Depth together account for 62% of your score. Both grade reasoning quality, not component recall. You can name-drop Kafka, DynamoDB, and consistent hashing and still score a 1 out of 5 if you can't explain why those choices fit this problem and not a different one.

The second thing most prep guides miss: senior and staff roles are scored differently on the same question.

• A senior candidate is expected to produce a plausible architecture and go deep on bottlenecks, consistency, and failure containment.
• A staff candidate is expected to challenge the problem statement itself — identify the highest-leverage version of what's actually being asked — and answer not just "how would you build this" but "should every team build this, and how would they migrate?"

Senior candidates frequently under-operate: the architecture is plausible but has no measurable workloads, no bottleneck analysis, no operational detail. Staff candidates commonly stay too abstract: strategy without a technically credible deep dive reads as commentary, not leadership.

---

System Design Interview Questions by Level: The Real Bar

These aren't generic lists. They're calibrated to what each level is actually expected to design — and what signals a mismatch.

SDE-2 / Mid-Level

At this level, you're expected to design a bounded product flow end-to-end. The interview tests whether you understand the core mechanics, can identify the 2–3 main trade-offs, and produce a coherent data model and API surface.

Questions that come up repeatedly:

• Design a rate limiter (token bucket vs leaky bucket vs sliding window log — know when each breaks)
• Design a notification system (push, email, SMS — fan-out strategies at 100M users)
• Design a URL shortener (seems trivial; the real test is consistent ID generation and redirect latency)
• Design a real-time chat system (presence detection, message ordering guarantees, offline delivery)
• Design Uber's core ride-matching (geohash vs H3, the supply-demand imbalance problem)

What gets SDE-2 candidates cut: premature scale theater. Adding Kafka, multi-region replication, and sharded databases before you've established the core read/write path. Mid-level candidates who propose distributed systems complexity for a problem that fits on a single Postgres instance signal that they've memorized patterns without understanding why those patterns exist.

Senior

Senior system design questions have a deliberate trap built in: the happy path is easy. The question is whether you volunteer the failure modes or wait to be asked.

Questions that come up repeatedly:

• Design Google Docs (real-time collaborative editing — OT vs CRDTs, not which one is "better" but why you pick one for this latency budget)
• Design a distributed cache (eviction policies, cache stampede protection, write-through vs write-behind)
• Design a payment system (idempotency, double-entry ledger, reconciliation — candidates who miss idempotency fail immediately at any fintech)
• Design a metrics and monitoring system (cardinality explosion in time-series DBs, pre-aggregation vs query-time aggregation)
• Design a code deployment system (blue/green vs canary, feature flags, rollback triggers)

What gets senior candidates cut: designing the happy path only. A senior candidate who describes the flow when everything works but has no answer for "what happens when the job worker crashes mid-processing?" is scoring a 2 out of 5 maximum at most companies. Interviewers at this level will inject failures. If you haven't pre-empted them, you've already lost points.

Staff

Staff system design covers platforms, not services. You're not designing one component — you're designing the system that other teams build their components on.

Questions that come up repeatedly:

• Design a distributed job scheduler (not just "use Quartz" — design the scheduler itself: leader election, job partitioning, at-least-once vs exactly-once semantics, dead letter queue)
• Design Apache Kafka internals (why does it use a log structure? how does consumer group rebalancing work? what breaks during a broker failure?)
• Design a multi-tenant LLM serving platform (model registry, quota management, fallback routing, per-tenant cost attribution)
• Design a stock exchange matching engine (low-latency order matching, the FIFO vs pro-rata allocation problem, circuit breakers)
• Design a distributed lock manager (what happens when the lock holder crashes before releasing?)

What gets staff candidates cut: staying too abstract. "We'll use a microservices architecture with event-driven communication" is a staff-level red flag. Staff interviewers will ask "should every team use this?" and "how do you migrate the 6 teams currently on the old system?" If you can't answer those with specific sequencing and risk trade-offs, you're not operating at the staff level regardless of how elegant your architecture diagram is.

---

Real Questions from Razorpay, Flipkart, Swiggy, Stripe, and Coupang

These aren't paraphrased. These are the actual question patterns candidates report from HLD rounds at these companies, with the specific constraint or twist that makes each one harder than the generic version.

Razorpay

Question: Design a payment notification system covering webhooks, push, SMS, and email with at-least-once delivery guarantees.

The generic notification system question is mid-level. At Razorpay, the twist is the delivery guarantee — and idempotency on the receiving end. Merchants must be able to call idempotency_key on their side to handle duplicate delivery; your system must deliver at-least-once and provide the tooling for merchants to make receipt idempotent.

What they probe: the state machine for a webhook delivery (PENDING → IN_FLIGHT → DELIVERED / FAILED), exponential backoff with jitter (not just "retry after failure"), HMAC signature on each delivery so the merchant can verify authenticity, and what your dead-letter strategy is after 72 hours of failed delivery.

What gets candidates rejected: Omitting idempotency keys. This is the single most common elimination at Razorpay. Designing a payment system without discussing idempotency — at a company whose core product is a payment gateway — signals you prepared for the generic interview, not this one.

Question: Design Razorpay's settlement system. Money flows from acquirer → Razorpay → merchant. Where can it fail and how do you reconcile?

This is a staff-level question. The reconciliation part is the actual test. You need: a double-entry ledger (every debit has a corresponding credit), a reconciliation job that runs after market hours and compares Razorpay's ledger against acquirer files (they batch-export settlement data), and a discrepancy queue for human review when the numbers don't match.

Flipkart

Question: Design the inventory and cart system for Big Billion Days — handling 1.5 million requests per second the moment the sale opens.

The generic "flash sale" question has a known answer: queue the requests, serve from cache, use atomic Redis operations for inventory reservation. Flipkart's actual Big Billion Days architecture adds three complications: the catalog has 100 million items but traffic concentrates on 0.1% of them; stock visibility is approximate (you don't show exact count, just "in stock / low stock / sold out"); and cart reservations expire in 20 minutes, which creates a thundering herd when 10,000 carts expire simultaneously at T+20 minutes.

What they probe: Redis atomic DECR with Lua scripts for oversell prevention (not just "use Redis"), the waiting room pattern to meter traffic before it hits your services, and what you do when a Redis node fails during a sale (strong consistency vs availability trade-off in the presence of a sale SLA).

Flipkart's actual Aerospike fleet serves ~90 million queries per second at sub-millisecond latency across search, pricing, and inventory. Candidates who answer "just use Redis" without discussing the data hot-spot problem — when every request hits the same key for a viral item — show they've memorized the pattern without understanding the failure mode.

Question: Design a recommendation system for Flipkart's product catalog that updates in near real-time based on in-session behavior.

Classic answer: offline collaborative filtering, item2vec, batch computation. The 2026 version of this question is the "in-session" constraint. You're browsing electronics; you viewed three noise-canceling headphones in the last 5 minutes. The recommendations should reflect that within 2–3 page loads — not after the daily retraining cycle.

What they probe: the distinction between offline candidate generation (pre-computed item embeddings in a vector DB) and real-time re-ranking (features from a Redis session store, lightweight model that can run in under 30ms). Candidates who only know batch ML pipelines can't answer the real-time re-ranking half.

Swiggy

Question: Design Swiggy's dispatch system — matching orders to delivery partners in real-time, with batching for efficiency.

This is three coupled problems: serviceability (can this restaurant reach this customer?), dispatch (which delivery partner picks up which order?), and batching (when do you hold an order briefly to pair it with another going the same direction?).

The dispatch matching is a weighted bipartite graph problem. The Hungarian algorithm solves it exactly in O(n³), but with thousands of active orders and hundreds of delivery partners, you need a bounded approximation: sample a subset of the closest partners, run the assignment on that subgraph, commit, and re-run as new orders arrive. This is what production systems actually do.

What they probe: geospatial primitives (H3 vs geohashing — H3 is hexagonal so neighbors are equidistant, geohash is rectangular and has edge distortion), the GPS data pipeline (out-of-order pings, deduplication, last-write-wins per partner ID), and peak load behavior: Swiggy's traffic profile has 70–80% of daily orders in two narrow windows (lunch and dinner). What happens to your dispatch system when 10× the normal order volume arrives in 90 minutes?

Stripe

Question: Design Stripe's webhook delivery pipeline — events from internal services must be delivered to merchant HTTP endpoints with at-least-once semantics.

Stripe delivers webhooks at-least-once and retries for up to 72 hours with exponential backoff. The design question has a subtle trap: merchants may receive the same event twice (network timeout between delivery and acknowledgment), so every webhook handler on the merchant side must be idempotent — but you're designing Stripe's side, not the merchant's. What you control: the delivery state machine, the retry schedule, the HMAC signature generation, and the endpoint health check that decides whether to keep trying.

What they probe: delivery state machine (QUEUED → ATTEMPTING → DELIVERED / WILL_RETRY / DEAD), HMAC-SHA256 signature so merchants can verify the payload came from Stripe (not optional — it's table stakes at Stripe), the circuit breaker on unhealthy endpoints (if a merchant's server is returning 500s consistently, back off more aggressively — don't flood a server that's already down), and the dead letter queue after 72 hours.

What separates senior from staff at Stripe: a senior candidate designs the delivery pipeline. A staff candidate asks: "What happens when our internal event bus produces a duplicate event before it reaches the webhook service? Now both the event bus and the delivery pipeline are idempotent — are there races between them?" That's the staff question, and it's the one that eliminates staff-level candidates who didn't think about end-to-end exactly-once guarantees across component boundaries.

Question: Design Stripe's multi-currency ledger.

Each money movement is an append-only double-entry entry: debit one account, credit another, same amount in the same currency. Multi-currency adds the FX conversion layer: the exchange rate at time of transaction must be locked in and stored with the entry — you can't recompute it later because rates change.

Coupang

Question: Design a high-throughput product search system for a 100-million-item catalog with real-time inventory visibility.

Coupang is vertically integrated — they own the last-mile delivery. This means the search results need to show not just "in stock" but "can deliver to your address by 7am tomorrow" (Rocket Delivery). The inventory signal is real-time: a warehouse scan 30 minutes ago can change the delivery window.

What they probe: hybrid search (BM25 for lexical matching + dense retrieval for semantic matching, combined via RRF), the inventory service integration (near-real-time updates from warehouse management systems via CDC on Kafka), and the geo-routing layer (which fulfillment center is closest, and does it have stock?). Candidates who answer "Elasticsearch + inverted index" without discussing the real-time inventory coupling are answering half the question.

Question: Design a distributed job scheduler that runs 10 million cron jobs daily across 500 worker nodes.

This is a staff-level question at Coupang but appears at senior-level too. The core design: a job store (Postgres with a scheduled_at index), a leader election service (using a distributed lock), workers that poll for jobs in their partition. The failure modes are the actual test: what happens when a worker takes a job but crashes before completing it? (Heartbeat-based lease expiry, not a simple timeout.) What happens when the leader crashes during job assignment? (Leader re-election must be idempotent — the new leader should not re-schedule jobs the old leader already handed out.) What happens when you add 100 more workers without downtime?

---

The 45-Minute Framework That Actually Works

This isn't a list of "tips." It's the specific time allocation and the exact behavior interviewers reward at each phase.

Minutes 0–5: Requirements (the phase most candidates rush)

Ask exactly four questions before touching the whiteboard:

1. Scale: What's the peak RPS? How many users? How much data?
2. Latency SLA: What's the p99 requirement for the critical path?
3. Consistency vs availability: In a partition, which do you sacrifice?
4. The scope constraint: "Should I design the full system, or focus on [the hardest component]?"

Why this matters: The answer to "10M users" vs "10B users" changes whether you need database sharding. The answer to "p99 < 50ms" changes whether you can use a relational DB or need an in-memory store. Candidates who skip this and assume the worst-case everywhere are doing scale theater. Candidates who skip it and assume best-case fail the follow-ups.

Minutes 5–10: Back-of-envelope estimation

Put actual numbers on your whiteboard. "1M RPM = ~17K RPS. Each request writes 1KB. That's 17MB/s write throughput. A single Postgres instance handles ~2–5K writes/sec, so I'll need sharding or a write-optimized store."

Interviewers reward numbers, not adjectives. "High traffic" is not a number. "17K RPS with 17MB/s write throughput" is a number that constrains your architecture choices.

Minutes 10–25: High-level architecture

Draw the boxes. Name the technologies. But for every technology choice, say the words: "I'm choosing X over Y because [specific trade-off for this workload]."

"I'd use Cassandra over Postgres here because the write volume is 50K/sec and I need linear write scaling — Postgres's write-ahead log becomes a bottleneck above ~10K/sec on a single node, and this workload doesn't need strong ACID guarantees across rows."

That's a 4-out-of-5 answer. "I'd use Cassandra because it scales well" is a 2-out-of-5 answer.

Minutes 25–40: Deep dive on the hardest component

Pick the component with the most interesting failure mode. This is where senior and staff candidates earn their score.

Go three levels deep:

1. The normal case (how it works when everything is fine)
2. The failure case (what breaks and how you detect it)
3. The recovery case (how you restore correctness, not just availability)

Minutes 40–45: Operational concerns

Cover three things proactively: monitoring (what metric tells you the system is degrading before users notice?), deployment (how do you roll out a schema change without downtime?), and cost (at 17MB/s write throughput continuously, your S3 costs are ~$40/day — is that in budget?).

---

The 5 Mistakes That Eliminate Candidates (Even Good Ones)

These aren't beginner mistakes. They're the mistakes that eliminate engineers with 5–8 years of experience who know the material but fail the interview.

Mistake 1: Technology before constraints

Starting with "I'd use Kafka for the event streaming" before establishing what the event volume is, what the latency requirement is, and whether ordering matters. This pattern signals memorized blueprints, not reasoning. The correct order: state the constraint, name the requirement it creates, then name the technology that meets that requirement. Kafka is the right answer to a specific set of constraints. Name those constraints first.

Mistake 2: The happy-path-only design

Designing a system that works when all components are up and all inputs are valid. Senior engineers fail when they don't address: what happens when the payment service is down mid-checkout? What happens when a Kafka consumer lags by 30 minutes? What happens when a user submits the same form twice (idempotency)? If your design has no answer to those questions, it's not a senior-level design — regardless of how elegant the happy path is.

Mistake 3: Consistency without a position

Saying "it depends on the use case" when asked about consistency vs availability is the system design equivalent of "it depends on requirements" in a coding interview. It's true — but it's not an answer. Take a position: "For the order creation flow, I'd choose consistency — a user should never see a successful order confirmation if the inventory wasn't actually reserved. I'll accept higher latency to get linearizability here." Then explain what you sacrifice.

Mistake 4: No numbers on the whiteboard

"High traffic," "large scale," "low latency" are not engineering specifications. An interviewer who hears these has no way to evaluate whether your architecture is sized correctly. Put numbers: 50K RPS, p99 < 100ms, 1TB/day write throughput. Your architecture choices should follow from those numbers. If they don't, the interviewer can tell you're designing in the abstract.

Mistake 5: Silent thinking for more than 30 seconds

System design interviews are communication tests as much as knowledge tests. Interviewers want to observe your reasoning process — not receive the output of it. Think out loud: "I'm choosing between fanout-on-write and fanout-on-read. Fanout-on-write pre-computes timelines for every follower — that's 5B fan-out events per day at Twitter's scale. Fanout-on-read is cheaper to write but more expensive to serve. Given we're optimizing for read latency, I'll use fanout-on-write for users with fewer than 10K followers and pull for celebrities." Thirty seconds of silence means the interviewer is missing signal on how you think. Give them the reasoning, not just the conclusion.

---

The Thing Everyone Gets Wrong: Confusing AI-Augmented Questions with ML Engineer Questions

System design interview questions in 2026 routinely include AI components. The mistake is treating this as a different category — the "ML question" that only ML candidates answer. It isn't. At Swiggy, Flipkart, Coupang, and Razorpay, senior SDE roles are expected to discuss ML components as naturally as they discuss databases and message queues.

"Design a product catalog search" is now an implicit question about hybrid search (BM25 + dense retrieval). "Design a feed ranking system" is an implicit question about online feature serving and model latency budgets. "Design a fraud detection system" is an implicit question about why you'd choose a gradient boosted tree over a neural network for the synchronous path (answer: 5ms inference on CPU, no GPU dependency, interpretable for compliance).

The engineers who clear these rounds know exactly one thing that others don't: AI is a component with latency, throughput, and failure characteristics, just like any other component. An embedding model that takes 200ms to generate a query vector is a bottleneck. A recommendation model that calls out to a feature store on every request is a network dependency. A fraud model whose score distribution shifts over time is a monitoring problem.

Treat AI components with the same engineering rigor you apply to databases: know their latency characteristics, know their failure modes, know when they degrade, and know how you'd detect it.

If you want to build fluency across these patterns — the full spectrum from classic HLD to AI-augmented system design — the system design module on KnowEase covers both, with structured practice problems that map directly to the question patterns at the companies in this guide.

---

Company-Specific Preparation: Quick Reference

| Company | Non-negotiable knowledge | The eliminator | |---|---|---| | Razorpay | Saga pattern, outbox pattern, idempotency keys, double-entry ledger | No idempotency = rejected; treat it as table stakes, not advanced | | Flipkart | Redis DECR with Lua for atomic inventory, waiting room pattern, Aerospike vs Redis trade-offs | Flash sale candidates who answer "just use Redis" without discussing hot-key sharding fail | | Swiggy | H3 vs geohashing, bipartite dispatch matching, GPS pipeline deduplication | Answering "Kafka + Postgres" for dispatch without mentioning the matching algorithm fails | | Stripe | Webhook state machine, HMAC-SHA256 delivery signing, double-entry FX ledger | Missing idempotency keys on the payments API is first-order rejection | | Coupang | Hybrid search (BM25 + dense + RRF), CDC-based real-time inventory, lease-based job ownership | Answering "Elasticsearch" for search without inventory coupling fails; real-time delivery window is the hidden constraint |

---

The Question That Will Still Matter in Three Years

Every system design question in this guide has a version that was relevant in 2020 and a version that's relevant in 2026. The underlying change is the same: the boundary between software systems and AI systems has collapsed. A senior engineer who can't reason about ML component latency and failure modes is like a senior engineer in 2015 who couldn't reason about distributed consistency.

The best way to prepare isn't to memorize more question answers. It's to build a reasoning framework that generalizes: understand the constraints, name the trade-offs, go deep on the failure modes, and treat every component — whether it's a database, a message queue, or a recommendation model — with the same engineering rigor.

The engineers who consistently clear these rounds at Razorpay, Flipkart, Swiggy, Stripe, and Coupang aren't the ones who prepared the most question-and-answer pairs. They're the ones who can reason through a question they've never seen before using a framework they've internalized.

For structured practice on the specific patterns in this guide — with rubric-based feedback on each answer — explore KnowEase's system design track and the companion distributed systems interview guide.