Step 1: Buy 90 seconds with clarifying questions.

You don’t need to know the answer before you ask the questions. “Let me make sure I understand the scope — are we designing for real-time delivery or batch? How many users at peak?” You’re not stalling — you’re genuinely narrowing the problem while your brain maps the question to the nearest archetype.

Subscribe for Question Walkthrough

Step 2: Name the archetype out loud.

“This sounds like it has the same core tension as a feed fanout system — lots of writes amplifying into lots of reads, with a latency constraint.” If you’re right, the interviewer will nod. If you’re wrong, they’ll redirect. Either way, you’ve signaled you have a framework.

Step 3: Run the 6-step framework on the archetype, not the specific question.

If you’ve identified it as a “real-time messaging” problem, run the messaging framework — WebSocket, delivery semantics, offline handling — and adapt the names to fit the new question.

Step 4: Go deep on the hard part, not the familiar parts.

If you’ve never seen the question before, the interviewer knows it. They’re not expecting a polished answer. They’re watching whether you can reason under uncertainty. Go to the hardest distributed systems problem in the question and show that you can think through it, even imperfectly.

What not to do: Don’t say “I haven’t seen this question before.” It signals that you were expecting to pattern-match, not think. Even if the question is new, treat it as a normal design round and work through it.

CTA: The cohort curriculum is built around recovering when the question is unfamiliar — clarifying the scope, identifying the right system archetype, applying a proven framework, and going deep on the hardest distributed-systems trade-off instead of relying on pattern-matching.

Subscription link

https://systemdr.systemdrd.com/subscribe

Want the full picture?

The premium lessons include advanced insights, practical exercises, and comprehensive walkthroughs.

Reddit’s front page is community-aggregated content ranked by the “hot” algorithm. The interesting system design question is: how do you maintain a ranked list across thousands of subreddits with millions of concurrent voters, without recomputing the full ranking on every vote?

The Hot Algorithm

This decays old posts naturally without a cron job — the time term shrinks the relative contribution of votes as a post ages. An hour-old post needs 10× more upvotes to rank above a brand-new post.

Architecture

- Vote events:

User upvotes → Kafka → vote aggregation worker → update posts.score in the posts table

- Front page:

Precomputed per-subreddit sorted lists in Redis ZSETs, score = hot algorithm value. On vote: re-score the post and ZADD with new score. Front page read = ZREVRANGE /r/all 0 24 — O(log N)

- The r/all problem:

r/all aggregates top posts from all subreddits. At peak, millions of posts compete. Maintain a separate ZSET for r/all, updated when any subreddit post’s score enters the top-1000 of its subreddit

- New posts:

Use a separate new ZSET per subreddit sorted by created_at. New tab = ZREVRANGE on this set. No algorithm needed.

- Award/controversy:

Track controversiality score (high upvotes AND high downvotes) in a separate sorted set for the controversial sort

Get Access to GitHub Repo

Read more

It’s the Google Docs question. Design a real-time collaborative editor.

Here’s why it’s the hardest — and why that makes it the most valuable one to understand deeply even if you never get asked it directly.

Why it’s different from every other question

Most system design questions have a “store data, serve data” structure underneath. Messages are stored and delivered. Files are stored and synced. Videos are stored and streamed. The interesting problems are about doing these operations reliably at scale.

Collaborative editing is different. The problem isn’t storage or delivery. It’s merging — two users type simultaneously into the same document, and both changes must survive in a consistent order on both clients, in real time, without either user’s edits being lost.

This is a fundamentally different problem. Storage and delivery can be solved with good distributed systems primitives. Merging concurrent edits requires a different class of solution: Operational Transformation or CRDTs.

Subscribe for Question Walkthrough

The naive approaches fail interestingly

Most candidates start with one of two intuitions.

The first: “the server is the source of truth — last write wins.” This silently destroys data. User A types “Hello” and user B types “World” simultaneously. Whichever write arrives at the server last overwrites the first. One user loses their edit invisibly. Not acceptable.

The second: “the server merges conflicting writes.” This sounds right until you try to implement it. What does “merge” mean for concurrent text edits? If A inserts a character at position 5 and B deletes a character at position 3 simultaneously, what’s the correct merged result? The positions have shifted. The server cannot naively apply both operations in sequence.

This is where OT comes in.

What Operational Transformation actually does

Each edit is represented as an operation: insert(position, character) or delete(position). When two operations are generated concurrently — before either user has seen the other’s edit — they must be transformed against each other before both can be applied.

The classic example: document is “Hello.” User A inserts “ World” at position 5. User B simultaneously inserts “!” at position 5.

After A’s operation, position 5 has shifted — “!” should now be inserted at position 11. The transform function adjusts B’s operation before applying it. Result: “Hello World!”

The server maintains a history of all operations. When it receives an operation, it transforms that operation against all operations the client hasn’t yet seen, then broadcasts the transformed version to all clients. The document converges to the same state on all clients.

Why this matters for questions you will get asked

Understanding OT deeply unlocks several adjacent concepts:

The operation log as a data model. An OT-based system stores operations, not document state. The document is the result of replaying all operations from the beginning. This is event sourcing — the same pattern used in payment ledgers, audit trails, and any system where history matters more than current state.

The difference between mutable and immutable data models. Most system design candidates default to mutable state (update the row when something changes). The operation log is immutable — you only ever append. Understanding why immutable append-only logs are often better than mutable state is one of the higher-order concepts in distributed systems.

CRDTs as an alternative. Conflict-free Replicated Data Types solve the same merging problem differently — by designing data structures where all operations commute (can be applied in any order and produce the same result). Notion uses CRDTs. Google Docs uses OT. Both work.

If you understand one of these deeply, you understand a design principle that appears in message delivery systems, distributed databases, version control systems, and collaborative tools.

The Google Docs question is hard because it requires understanding a class of problem — concurrent state merging — that doesn’t appear in most backend engineering work. But once you understand it, you see it everywhere.

The full walkthrough is in the Vault under Real-Time Messaging. The drill card is the most complex card in the set. Both are there when you’re ready to go deep.

CTA: The cohort curriculum is built around closing exactly these three gaps — state merging, immutable operation logs, and real-time OT mechanics

Subscription link

https://systemdr.systemdrd.com/subscribe

The deeper concepts start where this lesson ends.

Explore the premium content for advanced techniques and system-level thinking.

The API gateway is a cross-cutting infrastructure component that every FAANG-tier system uses. The question tests whether you understand authentication, rate limiting, routing, and load balancing as composable middleware layers — and what the operational challenges are when this component is in the critical path of every API call.

Step 1 — Clarify

- What features: auth, rate limiting, routing, load balancing, caching, request transformation, observability?

- Scale: 1M req/sec aggregate across all upstream services

- Multi-tenant (different customers, different routing rules) or single-tenant? - SLO: gateway latency overhead < 5ms p99 (adds < 5ms to every request)

Step 2 — Architecture

The middleware chain (executed in order for every request):

1. TLS termination — decrypt HTTPS at the gateway; upstream services communicate in plaintext within the datacenter

2. Authentication — validate API key or JWT token. Token validation: symmetric JWT (verify signature with shared secret, ~0.5ms) or asymmetric (fetch public key from auth service — cache aggressively, 24h TTL)

3. Rate limiting — per API key, per endpoint, sliding window counter in Redis (see Rate Limiter walkthrough)

4. Request routing — match URL pattern to upstream service. Stored in a routing table (Redis or in-memory hash map, updated via config push)

5. Load balancing — pick a healthy upstream instance (round-robin, least-connections, or consistent hash for sticky sessions)

6. Request forwarding — proxy the request to the upstream; handle upstream timeout and retry

7. Response transformation — add CORS headers, strip internal headers, compress response

8. Observability — emit request log, latency metric, status code metric to monitoring pipeline

Configuration plane: Routing rules, rate limits, auth policies are stored in a config database (etcd or Postgres) and pushed to gateway instances via pub-sub. Gateways cache config in-memory; config staleness of 30 seconds is acceptable.

Health checking: Gateway maintains a health map of all upstream instances. Active health checks (HTTP probe every 5s) + passive health checks (circuit breaker on error rate). Unhealthy instances removed from the load balancing pool.

Get Access to GitHub Repo

Read more

But the path to the interview room, the logistics surrounding it, and the context after an offer are different in ways that matter. Here’s what actually differs.

What’s genuinely different

The remote-first hiring pipeline. Most FAANG-tier companies now conduct all interviews remotely. This is an advantage for India-based engineers — you’re no longer at a geographic disadvantage for the initial loop. The downside: time zones. A loop with a US-based company typically means some interviews between 7:30 PM and midnight IST. This is worth planning around — don’t schedule a round at midnight if you have a critical work deadline the next morning.

Level calibration. A “Senior Engineer” at a well-regarded Indian tech company (Flipkart, Meesho, Swiggy, Juspay) maps to L4–L5 at Google/Meta depending on tenure and scope. An “architect” or “lead” at a larger Indian IT firm (Infosys, Wipro, TCS) typically maps to L4. This isn’t a judgment — it’s a calibration issue. Know your actual level going into the interview, not just your title.

The PPP pricing reality. FAANG-tier base salaries for India-based roles are significantly lower than their US equivalents — typically ₹40L–₹1.2Cr TC for L4–L6, versus $200K–$600K TC in the US for equivalent levels. This is expected and not negotiable in the same way US offers are. The negotiating leverage for India-based roles is typically in joining bonus and ESOP vesting schedules, not base.

Visa and relocation. If you’re targeting a US relocation, the current H-1B backlog for Indian nationals is 10–15 years. This is a real constraint. Some engineers time their loop specifically to target companies with large India offices or a clear path to a Canada/Singapore transfer as an intermediate step. Worth being explicit about your relocation preferences early in the recruiter conversation, not after the offer.

What isn’t different

The technical bar. Identical. The system design questions are the same. The rubric is the same. The expected depth for L5 in Bangalore is the expected depth for L5 in Seattle.

The preparation path. Identical. Cold drills, walkthroughs, mock interviews with peers. The prep that works in the US works in India. This newsletter covers both.

The failure modes. Identical. Scoping too broadly, communicating at the wrong level, not handling failure modes — the same mistakes fail the round everywhere.

The timeline pressure. Identical. Most engineers underestimate how long a loop takes. Initial screen, technical screen, onsite loop, offer, negotiation, background check — 6–12 weeks is typical. Plan accordingly.

One practical difference in preparation

The pool of practice partners in India is large but unevenly distributed. Engineers at Flipkart, Meesho, PhonePe, Razorpay, and similar companies have usually seen these interviews and can give calibrated mock feedback. Engineers at service companies may not have. Be deliberate about who you practice with — the value of a mock is entirely in the quality of the feedback.

The Discord has a regional channel specifically for India-based members. The #india channel is where timezone coordination, India-specific company intel, and INR pricing questions go. Post there if you’re looking for mock partners in IST.

The INR pricing

This newsletter’s paid content is available at ₹399/month or ₹2,999/year. The Vault is ₹9,999. The Cohort is ₹49,999. These are PPP-adjusted prices — the same content, different checkout link. Email with subject “INR pricing” and I’ll send the local currency link.

The technical content is identical regardless of which pricing you use.

CTA: The cohort curriculum is built around closing exactly these three gaps — each module targets one of them directly.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

The free lesson gives you the overview.

The premium version shows you exactly how to apply it step by step

Time-series data at massive scale. The interesting problem is write throughput (millions of metrics per second from thousands of servers) vs query throughput (interactive dashboards needing sub-second response over months of data). These two requirements pull the architecture in opposite directions — you optimize writes by sequential append, you optimize range queries by pre-aggregation.

Step 1 — Clarify

- What types of data: metrics (numeric time-series), logs (text events), traces (distributed request spans)? Scope to metrics.

- Ingestion rate: 1M metrics/sec (single large deployment)

- Query SLO: dashboard queries over last 24h should return in < 2 seconds - Retention: 15-second resolution for 24h, 1-minute resolution for 30 days, 1-hour resolution for 2 years

- Alerting required? (Yes — threshold-based and anomaly-detection alerts)

Step 2 — Estimate

- 1M metrics/sec × 8 bytes/datapoint = 8 MB/sec write throughput

- At 15-second resolution: 1M × 4 datapoints/min × 60min × 24h = 5.8B datapoints/day - At 8 bytes/point: 46 GB/day raw. Over 30 days: 1.4 TB

- With rollup (15s → 1min → 1h): ~50GB/month per compression tier

Get Access to GitHub Repo

Step 3 — Data Model

Time-series storage: Each metric is identified by a metric name + tag set (e.g., cpu.usage{host=web-01, region=us-east}). Stored as:

- Metric metadata: metric_id → {name, tags, retention_policy}

- Datapoints: (metric_id, timestamp) → value — ordered by timestamp, stored in a write-optimized time-series DB (InfluxDB, Prometheus TSDB, or custom LSM-tree)

Rollup tables: Three separate tables — raw (15s resolution), hourly (pre-aggregated to 1-minute), daily (pre-aggregated to 1-hour). Background jobs roll raw data up periodically, dropping the raw data after the retention window.

Read more

Here’s how to tell them apart and when to reach for each one.

What they have in common

All three decouple producers from consumers. Instead of Service A calling Service B directly, A puts a message somewhere and B reads it when it’s ready. This makes A and B independently scalable, independently deployable, and independently failure-tolerant.

The decoupling is the shared property. Everything else differs.

Kafka: streaming and fan-out

Kafka is a distributed log. Producers append messages to topics. Consumers read from topics at their own pace. Messages are retained for a configurable period (days or weeks), regardless of whether anyone has read them.

The key properties that distinguish Kafka:

Replay. A consumer can re-read old messages. If you deploy a new service and need to process all historical events, Kafka lets you rewind to the beginning. SQS and task queues don’t.

Fan-out. Multiple independent consumer groups can read the same topic simultaneously. Each group maintains its own offset. Service A and Service B can both consume the same stream of events without interfering with each other. SQS and task queues don’t support this natively.

Ordering. Messages within a partition are strictly ordered. If order matters — event sourcing, audit logs, ledger updates — Kafka preserves it.

Use Kafka when: you have multiple consumers that need to read the same events, you need replay capability, you’re building a streaming pipeline where order matters, or you need to decouple high-throughput event producers from slower consumers.

Don’t use Kafka when: you need guaranteed exactly-once delivery of individual work items to exactly one worker, or when you have a small team that can’t operationally support a Kafka cluster.

Subscribe for Question Walkthroughs

SQS: simple at-least-once work distribution

SQS is a managed queue. A producer enqueues a message. A consumer polls, processes, and deletes it. The message is invisible to other consumers during processing (the visibility timeout). If the consumer crashes, the message reappears.

The key properties:

Simplicity. Fully managed by AWS. No cluster to operate. You pay per message.

At-least-once delivery. Each message is delivered to at least one consumer. Duplicates are possible (rare but possible). Your consumer must be idempotent.

One consumer per message. Each message is processed by exactly one consumer group. No fan-out. If you need multiple services to process the same message, you need SNS in front of SQS (one topic, multiple queues).

Use SQS when: you need a simple, reliable queue for distributing work to a pool of workers, you’re on AWS, and you don’t need replay or fan-out.

Task queues (Celery, Redis Queue, Postgres FOR UPDATE SKIP LOCKED)

Task queues are purpose-built for job execution. A task has a type, a payload, a status, a retry count, and a deadline. Workers claim tasks atomically, process them, and mark them complete. Failed tasks retry with backoff.

The key properties:

Task lifecycle management. Task queues track the status of individual work items. You can query “which tasks are in progress right now” or “which tasks have failed more than 3 times.” Kafka and SQS don’t natively track per-item status.

Retry with backoff. If a task fails, it’s retried after an exponential delay. Dead-letter queuing for tasks that fail past the max retry count. This is the production pattern for background job processing.

Priority. Tasks can have priority levels. High-priority tasks jump the queue. Standard queues don’t support this natively.

Use a task queue when: you’re running background jobs (email sending, image processing, report generation), you need per-task status visibility, you need retry with backoff, or you need priority queuing.

The interview decision

In a system design interview, the choice should follow from the requirement:

Need multiple services to react to the same events? → Kafka
Need to offload work from a web request to a background process? → SQS or task queue
Need to build a streaming analytics pipeline? → Kafka
Need to retry failed jobs with backoff and track their status? → Task queue
Need a managed, simple work queue with no infra overhead? → SQS
Need replay capability for new consumers or debugging? → Kafka

The mistake to avoid: defaulting to Kafka for everything. Kafka is operationally heavy (unless you’re using Confluent Cloud or a managed service). For a small-scale job queue, Postgres with FOR UPDATE SKIP LOCKED is simpler, cheaper, and perfectly adequate up to millions of jobs per day.

State your choice, name the alternative you’re not using, and explain why. That’s the format for any technology decision in this category.

CTA: The full walkthroughs go beyond knowing what Kafka, SQS, or task queues are. They show you how to make the decision in an interview — what requirement should drive the choice, which alternative to rule out, and how to explain the tradeoff like a Senior vs Staff engineer.

If you found this valuable, the full library includes 52 walkthroughs, bonus lessons, exercises, and detailed interview breakdowns.

https://systemdr.systemdrd.com/subscribe

The web crawler question tests distributed systems breadth: politeness (don’t hammer a single server), deduplication (don’t re-crawl the same URL twice), scheduling (recrawl priority), and parsing at scale. The interesting distributed systems problem is managing a frontier of billions of URLs across a cluster of crawlers without duplication.

Step 1 — Clarify

Step 2 — Estimate

Get Access to GitHub Repo

Step 3 — Key Components

URL Frontier: A distributed priority queue of URLs to crawl. Priority based on: page importance (PageRank estimate), content freshness, recrawl deadline. Implemented as a two-level structure: an in-memory heap of high-priority URLs, backed by a disk-based queue (Kafka or a custom LSM-tree store) for the full frontier.

Deduplication: Before adding a URL to the frontier, check if it’s already been crawled. Use a Bloom filter (fast, probabilistic, O(1) membership check) to catch already-seen URLs. False positives acceptable (skip a valid URL) but false negatives not (avoid re-crawling). Secondary deduplication: content hash of the fetched page to detect mirror pages.

Politeness policy: Per-domain rate limiting. Maintain a domain_last_crawled map. Enforce minimum interval between requests to the same domain (e.g., 1 request/sec per domain). Respect robots.txt — fetch and cache per domain on first visit.

DNS pre-resolution: DNS lookup adds latency to every fetch. Pre-resolve and cache DNS for all domains in the frontier. TTL-matched to DNS record TTL.

Read more

Name two failure modes you haven’t fixed and the conditions under which you’d revisit the design.

Not generic failure modes. Specific ones from your design.

“The two things I’d revisit: first, if the celebrity threshold for switching from fanout-on-write to fanout-on-read turns out to be lower than 1M followers in practice — I’d tune it based on actual write amplification metrics after the first week in production. Second, if the change_log grows faster than anticipated — I’d add a compaction job earlier than the 30-day window I assumed.”

This demonstrates:

1. You understand your design is an approximation, not a solution.

2. You’ve already thought about the monitoring signals that would tell you it’s failing.

3. You know how to respond when it fails.

That’s the entire difference between a candidate who has read about systems and a candidate who has been on-call for them.

This is just the beginning. The premium content includes practical projects, frameworks, and deeper technical insights.

CTA: The Question Vault is organized by company and archetype, so you can focus your prep where it matters. Each drill card shows the specific questions, patterns, and probes to prioritize for your target company. All 52 walkthroughs are in the Vault.

https://systemdr.systemdrd.com/subscribe

—Sumedh

Subscribe Now

Unlike most system design questions, fraud detection has two hard constraints that conflict: latency (fraud checks must complete in < 100ms inline with the payment flow) and accuracy (false positives block legitimate transactions — costly; false negatives allow fraud — also costly). The architecture must serve both.

Step 1 — Clarify

- Inline (synchronous, blocks payment) or async (payment proceeds, flag for review later)? - Correct answer: both. Hard blocks for obvious fraud, async review for suspicious. - What signals are available: card data, user history, device fingerprint, IP, merchant category?

- False positive tolerance: rejecting 1% of legitimate transactions costs real revenue - Target: catch > 99% of fraud while blocking < 0.1% of legitimate transactions

Step 2 — Data Model

Get a Access to Github Repo

Step 3 — Architecture (two-layer)

Layer 1 — Inline rules engine (< 10ms): Hard rules that block obviously fraudulent transactions:

Implemented as: rules stored in Redis (fast read), evaluated in-memory per transaction. No ML — pure boolean rules. Fast enough to be fully synchronous.

Read more

After building the 52-question bank, I went back and tagged each question by which company most commonly asks it and at what frequency. The pattern is clearer than I expected.

Here’s what it shows — and what it means for your prep if you have a specific company in your loop.

Amazon

The most-asked question at Amazon is a variant of marketplace matching or recommendation. Design the product search system. Design the recommendation engine. Design the shopping cart and inventory reservation.

The probe Amazon reaches for most consistently: what happens at scale? The interviewers are looking for whether you’ve thought about the system failing under load, not just the happy path. Estimation with consequences is weighted heavily at Amazon because of the Well-Architected Framework culture internally.

If you have an Amazon loop: prioritize Uber Dispatch (geospatial matching), Amazon Product Search, and the Distributed Task Queue. The infrastructure archetype is also heavily represented at Amazon — URL shortener, API gateway, rate limiter.

Google

Google asks the hardest technical questions in the bank. The most-asked questions are in the search and infrastructure archetypes: web crawler, search autocomplete/typeahead, Google Docs (collaborative editing), distributed file systems.

The probe Google reaches for: can you go deep on the hard distributed systems problem? Google interviewers typically don’t probe breadth — they probe depth on one component until you hit the edge of your knowledge.

If you have a Google loop: prioritize the hardest question in each archetype (CRDT/OT for collaborative editing, consistent hashing for caches and sharding, bloom filters for crawlers). You won’t need to cover 10 questions in depth — you need to be able to go very deep on whichever question they ask.

Meta

Meta asks social feed questions at a much higher rate than other companies, which makes sense given the products: Facebook feed, Instagram feed, Stories, Reels. The fan-out architecture in all its variants is the most commonly asked pattern.

The probe Meta reaches for: the celebrity problem and how you handle it. Large-account fan-out is a real operational challenge at Meta’s scale, and every interviewer there has direct experience with the tradeoffs.

If you have a Meta loop: be extremely solid on Twitter Timeline (the canonical fanout question), Instagram Feed (adds ML ranking on top), TikTok-style recommendation (adds ANN search), and WhatsApp/Messenger (their messaging infrastructure).

Stripe

Stripe’s questions are almost all in the money movement archetype. Payments, fraud detection, ledger design, rate limiting for their API.

The probe Stripe reaches for: correctness under failure. Idempotency, double-entry ledger design, exactly-once-or-at-least-once semantics, what happens when a webhook fails and retries. Stripe engineers have to think hard about these problems in their actual work, and the interview reflects that.

If you have a Stripe loop: be very solid on Stripe Payments (especially idempotency keys), payment fraud detection, and distributed rate limiting.

Apple

Apple asks a lot of file sync and storage questions — makes sense given iCloud. Also streaming media (Apple Music, Apple TV+) and messaging (iMessage).

If you have an Apple loop: prioritize Dropbox/Google Drive, iCloud Photos, Spotify Audio Streaming (same patterns as Apple Music), and WhatsApp (same core as iMessage).

The pattern across all companies

Every company clusters around the products they actually build. The hardest preparation mistake is treating all 52 questions as equally likely.

If you have a specific company in your loop and 3 weeks to prepare, the most efficient path is: identify the 2–3 archetypes most relevant to that company, go deep on those archetypes, and do one solid drill per archetype. Then use the remaining time for your weakest archetype as a hedge.

Breadth matters less than targeted depth at this stage of prep.

CTA: The Question Vault is organized by company and archetype, so you can focus your prep where it matters. Each drill card shows the specific questions, patterns, and probes to prioritize for your target company. All 52 walkthroughs are in the Vault.

https://systemdr.systemdrd.com/subscribe

—Sumedh

Ready to level up?

Subscribe now

How to use this: Read your own submission first. Score it against the rubric. Then read this. Find the specific gap. That gap is what you drill this week. Don’t read this before submitting your own answer — the cold attempt is the point.

The question (recap)

Design a notification service. Users have devices; events generate notifications; notifications need to be delivered via push, email, SMS, or in-app depending on user preferences. Failures should retry. The system handles 100M users and 10M notifications per hour at peak.

Step 1 — Clarify

Before drawing anything, three questions matter most:

1. What triggers a notification? Internal events (new message, order shipped, payment received) vs external events (third-party webhooks). The answer shapes the ingestion layer — do producers call an API, or does the service subscribe to an internal event bus?

2. What delivery channels? Push (APNs/FCM), email (SendGrid/SES), SMS (Twilio), in-app (WebSocket). Each has different latency tolerance and reliability guarantees. Push notifications: best-effort, can drop. Emails: must deliver, queued. SMS: must deliver, expensive. In-app: only when the user is connected.

3. What are the SLOs per channel? Push notifications should fire within 5 seconds of the triggering event. Emails within 30 seconds. SMS within 60 seconds. In-app real-time (< 1 second). These numbers drive the queue and worker design.

Step 2 — Estimate

- 100M users, 10M notifications/hour peak = ~2,800 notifications/sec

- Channel distribution (typical): 70% push, 20% email, 8% in-app, 2% SMS - Push: 2,000/sec. Email: 560/sec. In-app: 224/sec. SMS: 56/sec

- Notification record size: ~500 bytes (user_id, channel, template, payload, status) - Storage: 10M/hour × 24h × 30d × 500 bytes ≈ 3.6 TB/month of notification history - User preferences: 100M users × 200 bytes per preference record ≈ 20 GB — fits in a single replicated RDBMS

The 70/20/8/2 channel split drives the worker pool sizing. Push workers handle 70% of the load and need the most horizontal scale.

Get Access to GitHub Repo

Step 3 — API Design

The dedup_key is the idempotency mechanism. If a producer calls /send twice for the same logical event (retry after a timeout), the duplicate is detected by dedup_key and the second call returns the original notification_id without re-queuing. Same pattern as Stripe’s idempotency key.

The template_id separates content from delivery. Producers don’t write notification text — they reference a pre-defined template and pass variables. This allows marketing/product teams to update notification copy without engineering deploys, and enables A/B testing of notification content independently of the delivery system.

Step 4 — Data Model

notifications table

One user has many device tokens. When sending push, the service fetches all active tokens for the user and sends to each. If a token comes back as invalid (APNs/FCM returns “unregistered”), mark is_active = false immediately.

Read more

Most advice about levelling up from L5 to L6 sounds like this: go broader, go deeper, show more impact, lead across teams.

All of this is true. None of it tells you what to do differently on Tuesday morning.

This post is the concrete version. What L6 actually adds in a system design interview, what experience you need before the interview will show it, and what to do in the next 90 days if you’re targeting L6 and currently at L5.

First: understand what L6 is actually assessing

The L5 interview asks: can you design a system that works?

The L6 interview asks: can you design a system that works, that you could operate at 3 AM when it’s failing, and that a team of 10 engineers could build and maintain without constant guidance from you?

Those are different questions. The first is technical correctness. The second is operational maturity plus organizational awareness. Preparing for L6 without understanding this distinction means you’ll produce an excellent L5 answer and wonder why it didn’t land.

Subscribe for Question Walkthrough

The three things L6 adds in the room

I’ve written about Senior vs Staff breakdowns in the paid walkthroughs, but let me be explicit here about what the additions actually are.

SLOs with monitoring signals. An L5 says “I’d target p99 < 100ms.” An L6 says “I’d target p99 < 100ms, and the signal I’d alert on is cache hit ratio dropping below 90% — that’s the leading indicator that Postgres load is about to spike. By the time the latency exceeds 100ms it’s already a problem, but the cache hit ratio tells me it’s about to be a problem while I still have time to act.”

That addition — the leading indicator, not just the threshold — takes 20 seconds to say and is the clearest operational maturity signal in a system design interview. L5 candidates almost never include it without being asked. L6 candidates include it naturally because they’ve been on-call and learned, usually painfully, that the metric you alert on is not the metric you care about.

The revisit condition. An L5 says “I’d partition by user_id because the hot read pattern is per-user.” An L6 says all of that and then adds: “The failure mode here is hot partitions if one user has disproportionate data volume. I’d monitor partition size variance in the first week and set up automatic re-partitioning if any shard exceeds 3× the average. That number is a starting hypothesis — I’d tune it based on actual data.”

The revisit condition shows that you’ve designed systems that later needed to be changed, and that you build in the instrumentation to know when to change them. This is genuinely hard to fake if you haven’t done it. It’s not a vocabulary signal — it’s an experience signal.

Organizational implications. This is the most L6-specific addition and the one most candidates skip entirely. After designing a payment notification system: “One thing I’d flag: this architecture creates a dependency between the payments team and the notifications team at the API contract level. If the notifications schema changes, payments has to coordinate. I’d define the notification contract as a stable interface owned by a platform team so that each product team can deploy independently.”

This sentence is completely invisible to an L5 candidate because L5 engineers generally work within one team and haven’t felt the cost of cross-team coupling. L6 engineers have — they’ve been the person blocked for two weeks because another team changed a shared interface without warning. That experience makes the organizational implication feel obvious to name.

What experience you need before the interview will show it

Here’s the uncomfortable truth: if you’ve spent your entire L5 tenure as an individual contributor on a single product team, building new features, the L6 interview will be hard regardless of how much you study.

L6 evidence is experiential. The monitoring signal addition requires having been on-call and learned what you actually alert on vs what you care about. The revisit condition requires having designed something that later broke in production and had to be changed. The organizational implication requires having felt the friction of cross-team coupling firsthand.

The 90 days before a targeted L6 loop should not just be interview prep. It should be deliberate experience accumulation:

Get on-call rotation, if you’re not already. Even 4 weeks of on-call for a production service will teach you more about operational maturity than any amount of walkthrough reading. You’ll learn what the leading indicators are, what the lagging indicators are, and what it feels like to have the wrong alert fire at 2 AM. That experience will show in the interview automatically.

Own a cross-team project, however small. Propose a shared API, a platform improvement, or a migration that affects two teams. Go through the coordination overhead. Feel the friction of interface ownership. When the interview asks about organizational implications you’ll have something real to draw on.

Write one design doc that gets scrutinized. Not a quick proposal — a full design doc reviewed by engineers senior to you who push back on your decisions. The experience of defending architectural choices against experienced criticism is directly transferable to the interview room.

The 90-day interview prep plan for L6

Given the above, the split should be different from an L5 prep plan.

Weeks 1–4: Get the experience if you don’t have it. See above. No amount of interview prep replaces the operational instincts that on-call builds.

Weeks 5–8: Drill specifically on L6 signals. For every question you drill, force yourself to add three things after the architecture: the monitoring signal for the most critical component, the revisit condition for the riskiest design decision, and the organizational implication of the biggest architectural boundary you introduced. These three additions are almost mechanical once you know to look for them.

Weeks 9–10: Two mock interviews. Ask the mock interviewer to specifically probe the L6 signals: “What would you alert on?” “What would make you reconsider this architecture?” “What does this mean for team autonomy?” If you can answer those three probes naturally in a mock, you’ll answer them naturally in the real interview.

Weeks 11–12: Consolidation. Same plan as any loop prep — drill cards, framework cheatsheet, one cold drill per day. Target the archetypes most relevant to your company.

What to do if your current role isn’t giving you L6 experience

Some engineers are targeting L6 at a new company because their current role doesn’t have the scope to build that experience. That’s a legitimate situation and worth being honest about.

The interview prep in that case should lean more heavily on vicarious experience: read incident post-mortems from engineering blogs (Cloudflare, Stripe, Datadog, and PagerDuty all publish detailed post-mortems). Read design documents from open source projects. Follow engineering blogs from companies operating at the scale of your target company.

The monitoring signal and revisit condition habits can be built by asking “what would tell me this design is failing?” after every drill, even if you’ve never been on-call. It’s not the same as lived experience, but it builds the reflex of thinking that way.

The organizational implication is harder to simulate. The closest substitute is: for every architectural boundary you draw in a design (this service vs that service, this team’s responsibility vs that team’s), explicitly name who owns the interface, what happens if either side changes it, and whether there’s a better way to isolate the two.

The question worth asking yourself

Before you start interview prep, sit with this for a few minutes: in the last six months, have you made architectural decisions that affected engineers outside your immediate team? Have you been woken up at 2 AM by a broken system and had to diagnose it? Have you owned an interface that another team depended on?

If yes to two or three: you probably have the experiential foundation and the interview prep is about learning to articulate it explicitly.

If no: the 90 days before your loop are more valuable spent accumulating those experiences than reading walkthroughs. The interview is a test of whether you think like an L6 engineer. That thinking comes from doing L6-level work, even briefly, more than from any amount of preparation.

The walkthroughs tell you what to say. The experience gives you something true to say.

CTA: The Senior vs Staff section in every paid walkthrough breaks down exactly what L6 adds for that specific question — not in the abstract, but with the exact phrases and decisions that separate Hire from Strong Hire at that level.

If you found this valuable, the full content library includes bonus lessons, exercises, and detailed breakdowns.

https://systemdr.systemdrd.com/subscribe

—Sumedh

The FYF is not a follow-graph feed — it’s a recommendation feed. The candidate pool is “every video ever uploaded” filtered by ML, not “videos from accounts you follow.” Same fan-out and ranking architecture as Twitter Timeline, but the candidate generation layer is completely different.

Step 1 — Clarify

- Follow-graph feed or pure recommendation? (FYF = recommendation — no follow required)

- Short video only (≤60s) or mixed? This drives storage and encoding decisions - Real-time engagement signals (likes, shares, completion rate) must feed back into ranking within minutes — how fresh?

- DAU? (TikTok: ~1B DAU globally)

- SLO: next video must load in < 500ms — the “infinite scroll” UX depends on it

Step 2 — Estimate

- 1B DAU × 40 videos watched/day = 40B video plays/day = ~463K plays/sec - Each user needs a pre-fetched queue of 10–20 recommended videos to enable instant scroll

- Candidate generation per user: rank top 500 from a pool of billions → return top 20 - Engagement events (play, like, share, skip): ~5 events per video = 200B events/day = 2.3M events/sec feeding the ranking model

Get Access to GitHub Repo

Step 3 — API Design

The prefetch_next_10 in the response is the key design signal — the client pre-fetches the next 10 videos while the user watches the current one, achieving the illusion of instant load.

Step 4 — Data Model

- videos table: video_id, creator_id, s3_key, duration_ms, transcript, embedding (vector), tags[], upload_at

- engagement_events (Kafka → time-series store): user_id, video_id, event_type, watch_pct, timestamp

- user_interest_profile: user_id, topic_vectors[], creator_affinity[], updated_at — updated continuously from engagement stream

- video_recommendation_cache (Redis): user_id → [ordered list of 50 pre-ranked video_ids, TTL=10min]

Read more

This phrase ends more system design answers than any other. It sounds thoughtful. It signals nuance. And it is the single most effective way to tell an interviewer you don’t know how to make a decision.

Every technology choice depends on the use case. That’s not an answer — it’s a preamble. The answer is what it depends on, and how you decide.

Here’s the decision framework for choosing between relational and non-relational storage that works in an interview setting.

Step 1: Write down your two hottest queries

Before naming any storage technology, write down the two or three queries the system will run most frequently. Specifically: what are the inputs, what are the outputs, and what constraints do they have?

“Give me all messages for user X, ordered by time” — this is a range query on a partition key. Wide-column store handles this well.

“Give me all orders for account X with status=pending, joined to the product table” — this has a join. Relational database handles this better.

“Give me the 10 nearest restaurants within 5km of this coordinate” — this is a spatial query. PostGIS or a geohash index.

The storage decision follows from the query. The query never follows from the storage decision.

Subscribe for Payments Walkthrough

Step 2: Apply the decision rules

Use a relational database when:

• Your data is structured and schema is stable

• You need ACID transactions across multiple rows or tables

• Your queries involve joins, aggregations, or complex filtering

• Your write volume is under roughly 5–10K writes per second per node

• Your total data per table is under roughly 100M rows before sharding gets painful

Use a wide-column store (Cassandra, HBase) when:

• You need high write throughput (100K+ writes per second)

• Your queries are predictable and partition-key-based — no joins, no ad-hoc filtering

• Your data is naturally time-ordered (events, messages, metrics)

• You need built-in TTL on rows (messages that expire, session data)

Use a key-value store (Redis, DynamoDB) when:

• Your reads are pure point lookups by a single key

• You need sub-millisecond latency

• You’re storing simple values or small objects

• You need atomic counters or sorted sets

Use object storage (S3) when:

• You’re storing large binary objects (files, images, video, backups)

• You need very high read throughput via CDN

• Latency of 50–200ms per request is acceptable

Step 3: Name the anti-pattern you’re avoiding

The most powerful version of a storage decision isn’t “I’d use Cassandra.” It’s “I’d use Cassandra instead of Postgres here because the write volume — 50,000 events per second — will exceed what a single Postgres instance can handle, and the queries are all partition-key-based so I don’t need the join capability I’d be giving up.”

The comparison forces you to show you considered the alternative. The reason forces you to show you understand the trade-off.

The one rule that overrides everything

If you need a multi-row ACID transaction — an operation where either all rows change or none do — you need a relational database or a relational-compatible distributed database (CockroachDB, Spanner). No amount of Cassandra tuning gives you true ACID across multiple partition keys.

Payment systems almost always need ACID. Account balances must be updated atomically. Inventory reservation must be atomic. Order creation and payment capture must be atomic.

“I’d use Cassandra for the payment ledger” is a common answer that fails almost every payment system design question. The interviewer will ask “what happens if the debit succeeds but the credit fails?” and there is no good answer with Cassandra.

Know what you’re trading away before you trade it.

CTA: The Stripe Payments walkthrough goes deep on exactly this decision — why the ledger needs ACID, how double-entry accounting makes the atomicity requirement explicit, and what happens at the infrastructure level when you enforce it. Paid post #2.

Interested in mastering this topic?

Unlock premium content with deeper explanations and real implementation patterns.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

The inventory reservation problem. A listing is available on specific dates, and two users trying to book the same listing for overlapping dates cannot both succeed. The hard problem: prevent double-booking without making the availability check and reservation a single-threaded bottleneck.

Step 1 — Clarify

- Single room per listing (Airbnb) or multiple rooms (hotel)?

- Search: by location + date range + filters?

- Booking flow: instant book (reserve immediately) or request-to-book (host approves)? - How to handle the “someone else just booked it” race condition?

Step 2 — Data Model

listings: listing_id, host_id, title, location, price_per_night, instant_book (bool) availability: listing_id, date, status (available/blocked/reserved), booking_id (nullable) PRIMARY KEY: (listing_id, date) — one row per listing per night

bookings: booking_id, listing_id, guest_id, check_in, check_out, status

(pending/confirmed/cancelled),

total_price, idempotency_key, created_at

The availability table with one row per listing per night is the key data model decision. Date range availability check = SELECT COUNT(*) FROM availability WHERE listing_id=X AND date BETWEEN check_in AND check_out AND status=’available’. If count = (check_out - check_in) in days, all nights are available.

Get Access to GitHub Repo

Step 3 — Reservation flow (preventing double booking) BEGIN;

-- Check all nights available and lock them

The FOR UPDATE lock on the availability rows means only one transaction can proceed for any given listing+date combination. The second concurrent booking attempt blocks, then fails the count check when it finally runs.

Read more

The most common reason technically strong candidates get a “Hire” instead of “Strong Hire” is not technical depth. It’s running out of time before demonstrating it.

The deep dive section — the hard distributed systems problem at the center of the question — is where L5 separates from L4, and where L6 separates from L5. It’s also the section that gets cut when the interview runs short. You spent 20 minutes on estimation and API design and now you have 10 minutes left for the architecture and zero for the deep dive.

The fix is specific time checkpoints that you self-enforce in the room. Not approximate — specific.

The 50-minute allocation

Here is the allocation that consistently produces complete answers with time for depth:

Total: 45–47 minutes, leaving a 3–5 minute buffer.

Subscribe for Question Walkthrough

The checkpoints to self-enforce

Minute 10: API must be drafted and scope must be locked. If you’re still asking clarifying questions at minute 10, you’ve spent your estimation time and you’ll have to compress the data model.

Minute 22: Schema and key flows should be on the board. At this point you should have: at least two tables sketched with primary keys and indexes, and at least one paragraph of the architecture explained. If you’re still on API design at minute 22, move immediately.

Minute 35: The deep dive must be in progress. Not about to start — actually underway. If you’re at minute 35 with only the high-level architecture sketched and no deep dive started, you have a problem. Stop the high-level walkthrough and pivot to the deep dive now. An incomplete high-level architecture plus a solid deep dive is worth more than a complete architecture with no deep dive.

Minute 48: Trade-offs and failure modes should be underway. If you’re still deep-diving at minute 48, spend the last two minutes naming the top three things that break in your current design and what you’d do about them. Even naming them without a full answer is better than silence.

The discipline required

The hardest part of time management is stopping something that’s going well to move on.

You’re mid-explanation of the data model. It’s going well. You understand this part. The interviewer is nodding. You want to finish the thought.

Move anyway. The next section matters more than this one continued.

The data model section’s job is to demonstrate that you can design appropriate schemas with the right indexes and sharding strategy. Once that’s demonstrated — once you’ve covered the main table, the partition key, and at least one non-obvious design decision — the section is done. More detail doesn’t add signal; it steals time from sections where signal is still available.

What to do when you fall behind

If you realize you’re behind the checkpoints, the correct response is compression, not panic.

For the architecture: “Let me give you the key components and the main flows rather than a complete walkthrough.” Five minutes instead of ten. Names the components, traces one read path and one write path, stops.

For the data model: “The critical table here is the messages table — let me focus on that one rather than all five tables.” Two minutes instead of seven. Names the partition key, names the TTL strategy, stops.

For the API: “Three endpoints — the core create, read, and webhook. Let me sketch those quickly.” Two minutes. Moves on.

Compression is always better than omission. A compressed section signals that you know what you’re doing and are managing time deliberately. An omitted section is a missing signal.

The permission to be incomplete

Most engineers feel they should finish each section before moving to the next. This intuition works in normal engineering work. In a timed interview, it’s wrong.

The interview is scored as a whole, not section by section. A round with complete clarification, estimation, API, data model, architecture, deep dive, and trade-offs — each at 70% coverage — scores better than a round with perfect clarification, estimation, and API at 100% coverage with no deep dive.

The deep dive is the section with the highest score differential. It’s where the round is decided. Everything before it is the setup. Don’t let the setup consume so much time that the payoff never arrives.

CTA: The drill cards have a time-box bar at the bottom of every card — the exact minute allocation for that specific question, weighted toward where the probe lands. All 37 are in the Vault.

Curious how this works in real systems?

The paid lessons cover scalability, optimization, and real-world engineering patterns.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Same fan-out architecture as Twitter Timeline, but the ranking model is more complex — Instagram ranks not just by recency but by predicted engagement (like, comment, share probability) for each specific user-post pair. The probe is the ranking pipeline and how features are assembled at query time without violating the 500ms SLO.

Architecture delta from Twitter Timeline

Read more

They’re not exotic. They’re not about knowing obscure algorithms. They’re about the difference between an answer that sounds right and an answer that demonstrates you understand what you’re designing.

Gap 1: Numbers that don’t drive anything

Most cohort members can estimate. They get DAU, they calculate requests per second, they calculate storage. The numbers are usually in the right order of magnitude.

Then the next section of their answer proceeds as if the numbers never existed.

“We’ll have approximately 50,000 writes per second” followed by “I’d store user data in a Postgres database.” No mention of whether Postgres handles 50,000 writes per second. No acknowledgment that this number might matter for the technology choice.

The numbers should be the reason for the architectural decisions. Not a box checked before the real answer begins.

The fix is simple: after every estimation number, add one sentence starting with “this means.” 50,000 writes per second — this means a single Postgres instance will be the bottleneck; I’ll need to either shard or move to a write-optimized store like Cassandra. Now the number is doing work.

Gap 2: The happy path only

Most cohort submissions design a system that works when everything goes right. The API is called, the database responds, the message is delivered. The walkthrough is coherent.

Then nothing goes wrong. There are no failure modes. There’s no offline user, no database timeout, no cache failure, no duplicate message delivery.

The simplest version of this is in the messaging question: a candidate designs the delivery path for an online user but never addresses what happens when the recipient is offline. The question literally asks about this. The omission is not subtle.

The fix is one explicit section at the end of every design: “three things that break.” Name them, name the conditions, and describe how you detect and handle each. Even if the answer is “we’d accept degraded behavior and alert on it” — that’s a real answer.

Subscribe for Question Walkthrough

Gap 3: Decisions without reasons

“I’d use Kafka for the event stream.”

Why Kafka? This sentence appears in dozens of submissions every cohort. Sometimes Kafka is the right answer. Sometimes a simple SQS queue would be better. Sometimes a database table with FOR UPDATE SKIP LOCKED is better. The choice depends entirely on the requirements.

When you state a technology choice without a reason, you’re signaling that you know the word, not the trade-off. The interviewer probes exactly here. “Why Kafka over something simpler?” is one of the most common follow-up questions in design interviews.

The fix is to never name a technology without one of these two phrases following it: “because” or “instead of.”

“I’d use Kafka because the producers and consumers have different throughput — decoupling them lets each scale independently.” Now the choice has a reason.

“I’d use Redis instead of Memcached because we need persistence and sorted sets for the leaderboard.” Now the choice has a comparison.

Why these gaps matter more than knowledge gaps

The three things above — numbers with consequences, failure modes, and reasoned decisions — are what experienced engineers do automatically when they design systems. Not because they’re trying to impress anyone. Because they’ve been on-call for systems that failed when the failure mode wasn’t anticipated, and they’ve had to defend technology choices to skeptical colleagues.

The interview is asking: does this person think like someone who has built and operated real systems?

The three gaps signal no, even when the technical knowledge is there.

If your answers have all three gaps, the fix is not more studying. It’s one mock interview where you discipline yourself to add “this means,” “three things that break,” and “instead of” to every section of your answer.

CTA: The cohort curriculum is built around closing exactly these three gaps — each module targets one of them directly.

Subscription link

https://systemdr.systemdrd.com/subscribe

—Sumedh

Curious how this works in real systems?

The paid lessons cover scalability, optimization, and real-world engineering patterns.

Slack is WhatsApp + channels + threads + search.

The messaging core is identical to WhatsApp (WebSocket, Cassandra, delivery semantics). The probes unique to Slack: channel message fan-out (a channel with 10,000 members means one message = 10,000 deliveries), message threading (replies live in a separate namespace from channel messages), and full-text search over message history.

Step 1 — Clarify

- Direct messages only, or channels + DMs + threads? (Scope to channels + DMs) - Search over message history? (Yes — search is a major Slack differentiator) - Max members per channel? (Slack allows ~10K for standard, unlimited for Enterprise Grid)

- File sharing? (Yes — same object storage pattern as WhatsApp media) - SLO: message delivery < 200ms p99 within same workspace

Step 2 — Estimate

- 20M DAU × 200 messages/day = 4B messages/day = ~46K messages/sec - Average channel size: 50 members → fan-out 50 deliveries per message - Large channels (10K members): 1 message = 10K WebSocket pushes - Message retention: Slack keeps all history (unlimited on paid plans) → ~500 bytes/msg × 4B msgs/day × 365 days = ~730 TB/year

Get Access to GitHub Repo

Step 3 — API Design

WebSocket: wss://slack.com/connect (per workspace per device)

ts (timestamp) is Slack’s actual message ID — a Unix timestamp with microsecond precision, unique per channel.

Step 4 — Data Model

- messages (Cassandra): PARTITION BY channel_id, CLUSTER BY ts DESC — identical pattern to WhatsApp but scoped to channel

- threads: thread_ts (FK to parent message ts), reply messages in same table with thread_ts as additional cluster key

- channel_members: channel_id, user_id, joined_at — indexed both ways (channel→members for fan-out, user→channels for sidebar)

- search_index (Elasticsearch): message ts, channel_id, text, user_id, timestamp — updated async via Kafka consumer

- unread_counts (Redis): user_id:channel_id → {unread_count, last_read_ts} — updated on every message and read event

Read more