Interview Scenarios

Full end-to-end system design walkthroughs using the same 8-step framework that top candidates use. Each scenario is a real interview question — practice them until the framework becomes second nature.

The 8-Step Framework

1. Requirements
2. Estimation
3. High-Level Design
4. Component Deep Dive
5. Database Schema
6. API Design
7. Scalability
8. Monitoring
Scenarios completed0/40(0%)

Design URL Shortener (TinyURL)

Design a URL shortening service like TinyURL or bit.ly.

This problem looks trivially simple on the surface -- and that is exactly why interviewers love it. You might think, 'It is just a key-value store with a redirect, right?' But then they start asking: how do you generate short codes without collisions across 10 servers? How do you handle 100x more reads than writes? How do you do the math to prove 7 characters is enough?

What is actually being tested here:
• Can you do back-of-envelope math under pressure? (base62 encoding, capacity planning)
• Do you understand caching at an architectural level, not just 'add Redis'?
• Can you reason about distributed ID generation -- a problem that trips up most candidates?
• Do you know the difference between 301 and 302 redirects and why it matters?

Most candidates jump straight into drawing boxes. The strong candidates start with the math: how many URLs, what read-write ratio, how long should the code be. Let the numbers drive the design.

45 minutes
Start

Design a social media platform / X Feed

Design a social media platform like a social media platform/X where users can post short messages (tweets), follow other users, and view a personalized home timeline.

Here is the thing about this problem: it looks like a simple social app, but the moment the interviewer says '50 million followers,' it transforms into one of the hardest distributed systems questions out there. The question they are really asking is: when someone with 50 million followers tweets, how do you get that tweet into 50 million timelines without the system falling over?

This is the fanout problem, and it is what the entire interview hinges on:
• You COULD pre-compute every follower's timeline when a tweet is posted (fanout-on-write). Great for reads. But 50M Redis writes per celebrity tweet? That takes hours
• You COULD compute timelines on the fly when someone opens the app (fanout-on-read). No write amplification. But 200M daily users each querying hundreds of accounts? Your database melts
• The answer is neither extreme — it is a hybrid that uses both. And explaining WHY you need the hybrid is what separates senior candidates from junior ones

If you walk away with one insight, it is this: the fanout strategy is not just a Twitter thing. It is the fundamental tradeoff in any system delivering personalized content at scale — activity feeds, notification systems, news aggregators. Master this pattern and you can answer a dozen different interview questions.

45-60 minutes
Start

Design a messaging platform / Messenger

Design a real-time messaging system like a messaging platform that supports 1:1 messaging, group chats, delivery receipts (sent/delivered/read), online presence, and media sharing for 2 billion users.

Here is what makes this problem fundamentally different from designing a social feed or a URL shortener: every other system we design is request-response. A client makes a request, a server responds. Messaging flips this on its head — the server needs to PUSH data to clients at any moment, which means persistent connections. You are managing 500 million WebSocket connections. That is the core constraint everything else flows from.

The three things the interviewer is really testing:
• Can you reason about stateful connections at planetary scale? 500M concurrent WebSocket connections across thousands of servers — how do you route a message from Alice on Gateway Server 47 to Bob on Gateway Server 832?
• Do you understand delivery guarantees? 'Sent' vs 'delivered' vs 'read' is not just a UI feature — it reveals whether you understand acknowledgment protocols and at-least-once delivery
• Can you handle the offline problem? What happens to messages when the recipient has no internet for 3 days? They cannot be lost, they must arrive in order, and the system cannot fall over when 100M users reconnect on Monday morning

Premium Access
Sign in

Design YouTube / the streaming platform

Design a large-scale video streaming platform like YouTube or Netflix.

Here is the mistake almost every candidate makes with this problem: they spend 30 minutes designing an upload and transcoding pipeline, run out of time, and barely mention the CDN. That is backwards. The CDN IS the system. Over 90% of all bytes served come from edge servers, not your origin. If you start your answer with 'let me talk about the CDN first,' you are already ahead of 80% of candidates.

This system is really two completely different systems wearing a trench coat. The write path (upload and transcoding) is an asynchronous job processing pipeline — queues, GPU workers, retries, nothing latency-sensitive. The read path (streaming) is brutally latency-sensitive — video playback must start within 2 seconds, segments must arrive faster than they are consumed, and adaptive bitrate must adjust in real time.

The numbers are staggering: 750 TB of raw video ingested daily, 3-5 PB of total storage growth per day (after all renditions), 100+ Tbps of peak streaming bandwidth globally. If the math does not scare you a little, you are not doing it right.

Premium Access
Sign in

Design Instagram

Design a photo and video sharing social network like Instagram that supports uploading media, following other users, generating a personalized feed, and ephemeral Stories.

Here is the number that should be on the whiteboard before you draw a single box: for every photo uploaded, it is viewed thousands of times. The read-to-write ratio is 100:1. That single fact tells you two things immediately: (1) the CDN is king — over 90% of all traffic is media delivery from edge servers, and (2) you need pre-computed feeds so that the most common operation (opening the app and scrolling) is blazing fast.

What makes Instagram distinct from a social media platform feed design is the media pipeline. Every photo goes through a multi-resolution processing pipeline that generates 5 versions, from a tiny 150px thumbnail to the full 1080px original. Why? Because a phone on 3G should not download a 4K image. The CDN serves the right size for each device. This is the kind of practical engineering detail that separates real-world designs from academic ones.

You will also encounter the same hybrid fanout pattern from the social media platform problem, an image processing pipeline similar to YouTube's transcoding, and a clever Stories subsystem that uses Redis TTL for automatic 24-hour expiration — no cron jobs, no cleanup logic.

Premium Access
Sign in

Design a Ride-Sharing Platform

Design a ride-hailing platform that matches riders with nearby drivers in real time, tracks live driver locations at massive scale (1.5M updates/sec), calculates dynamic surge pricing, and manages the full trip lifecycle from request to payment.

Why this is one of the hardest system design questions:
Here is the thing -- most system design problems are fundamentally about CRUD with caching. This one is not. You are building a real-time spatial search engine that has to answer the question "who is the closest available driver right now?" across millions of moving objects, and you have about 3 seconds to get that answer before your user gives up and opens a competitor's app.

• Real-time geospatial indexing across millions of active drivers -- every driver's position is stale within 4 seconds
• Sub-second matching with road-distance ETA calculations -- straight-line distance is useless in cities with one-way streets
• Globally distributed architecture handling millions of concurrent mobile connections -- and these are persistent WebSocket connections, not stateless HTTP
• Dynamic surge pricing reacting to supply/demand within seconds -- get this wrong and you either strand riders or bankrupt drivers

Premium Access
Sign in

Design Dropbox / Cloud Storage

Design a cloud file storage and synchronization service like Dropbox or Cloud Storage. Users can upload, download, and sync files across multiple devices with near-instant propagation.

Why this question separates mid-level from senior candidates:
The naive approach is to upload and download whole files. A junior engineer stops there. But here is what makes this problem genuinely hard: a user edits one paragraph in a 100 MB PowerPoint file. Do you re-upload the entire 100 MB? At scale, that would bankrupt you on bandwidth costs and make sync painfully slow. The key insight is that file sync is really a block-level diffing and deduplication problem -- and once you see that, the entire architecture clicks into place.

The system must handle block-level delta sync, deduplication, and conflict resolution at massive scale -- 700M+ users storing petabytes of data.

Premium Access
Sign in

Design a major cloud provider E-Commerce

Design a large-scale e-commerce platform that supports product browsing, search, shopping cart management, checkout with payments, and order fulfillment. The system must handle 300 million products, millions of orders per day, and extreme traffic spikes during events like Black Friday -- all while guaranteeing inventory correctness so no customer ever pays for an item that is already sold out.

What makes this different from a basic CRUD app:
Most candidates start drawing boxes for 'product service' and 'order service' and call it done. But the real challenge here is the tension between two conflicting requirements: the browse path needs to be blazing fast (sub-200ms search across 300M products), while the checkout path needs to be bulletproof (never oversell, never double-charge, never lose an order). These are fundamentally different engineering problems -- one is read-heavy and latency-sensitive, the other is write-heavy and correctness-critical. The architecture must handle both simultaneously, especially during a 10x traffic spike on Black Friday.

Premium Access
Sign in

Design Rate Limiter

Design a distributed rate limiter that sits in front of your API servers and throttles requests based on configurable rules. Rate limiting is the first line of defense against abuse, DDoS attacks, and accidental traffic spikes.

Why interviewers love this question:
Here is the thing -- the algorithm part is not the hard part. Token Bucket and Sliding Window are well-documented. What makes this question genuinely tricky is the DISTRIBUTED aspect. You have 50+ API servers, and each one needs to know the global count of requests from a given user. If each server tracks its own count locally, a user with a 100 req/min limit can send 5,000 requests (100 per server x 50 servers) without being throttled. The real challenge is achieving atomicity of the check-and-increment operation across a distributed fleet without adding meaningful latency to every single API request.

What you will design:
• A system that supports multiple algorithms (Token Bucket, Sliding Window Counter, etc.) -- but more importantly, the ability to switch algorithms per rule without redeploying
• Multi-level rules (per-user, per-API-key, per-IP, global) with cascading checks that short-circuit on the first violation
• Correct behavior across a fleet of 50+ API servers backed by a shared Redis cluster -- and graceful fail-open behavior when Redis goes down, because the rate limiter must never become the cause of an outage

Premium Access
Sign in

Design Notification System

Design a scalable notification system that delivers messages across multiple channels -- push notifications (iOS/Android), SMS, email, and in-app. The system must handle billions of events per day, respect user preferences, de-duplicate messages, and prioritize delivery based on urgency.

Why this question is deceptively hard:
Most candidates draw a message queue with some workers and call it done. But here is what they miss: the REAL challenge is not sending messages -- it is ensuring that a marketing blast to 100 million users does not delay someone's two-factor authentication code by even one second. That is a priority isolation problem, and it requires fundamentally separating critical and non-critical notification paths. The second hidden challenge is de-duplication -- in a distributed system with retries, the same event can trigger the same notification multiple times, and users will absolutely notice (and complain) if they get the same 'your order shipped' push notification three times.

Premium Access
Sign in

Design Web Crawler

Design a distributed web crawler that can download and process 1 billion web pages per day. The crawler must respect robots.txt, avoid re-crawling duplicate content, prioritize important pages, enforce politeness policies (rate limits per domain), and schedule re-crawls to keep content fresh.

Here's why interviewers love this question: it forces you to juggle multiple distributed systems problems at once, and they all interact with each other in subtle ways. Politeness limits your throughput, deduplication limits your frontier size, and priority scheduling determines whether you spend your crawl budget on pages that actually matter. Most candidates design the Fetcher and stop there -- the ones who get hired nail the Frontier design and explain how every component constrains the others.

Premium Access
Sign in

Design Typeahead / Autocomplete

Design a typeahead (autocomplete) system like Google Search Suggestions. As a user types each character, the system returns the top-K most relevant suggestions in real time.

This problem looks simple on the surface -- 'just use a trie, right?' -- but the real complexity is hiding in the latency constraint. Every keystroke fires a request, and users perceive anything over 200ms as sluggish. So you are building a system that handles 3.5 million prefix lookups per second at peak, blends global popularity with personalized signals, filters offensive content, and detects trending topics in near-real-time -- all within 100ms p99. The candidates who get this right understand that it is fundamentally a battle between precomputation and freshness.

Premium Access
Sign in

Design Distributed Cache

Design a distributed caching system like Redis Cluster or Memcached that can serve 100M+ requests per second with sub-millisecond p99 latency. This is an infrastructure-level question that tests your understanding of consistent hashing, cache coherence, replication, eviction policies, hot key mitigation, and failure recovery.

Here's what makes this question different from most system design interviews: you cannot hand-wave the numbers. When your latency budget is under 1 millisecond, every network hop, every serialization step, every lock acquisition shows up in your p99. Interviewers will push you on the math -- how many nodes, how much memory per node, what happens when a node dies. If you say 'just add more servers,' they will ask you to prove that consistent hashing moves only 1/N of the keys. This is a question where precise reasoning wins.

Premium Access
Sign in

Design Chat System

Design a large-scale real-time chat system supporting 1-on-1 conversations, group chats, read receipts, typing indicators, presence (online/offline/last seen), offline message delivery, message search, and end-to-end encryption.

Here's why this is one of the hardest system design questions: it sits at the intersection of problems that are each individually challenging. You need persistent WebSocket connections at a scale most engineers have never touched (500M concurrent). You need reliable message delivery with ordering guarantees -- even when the recipient is offline for days. You need fan-out strategies that work for both a 2-person chat and a 100,000-member group without blowing up your write amplification. And you need to reason about E2E encryption where the server is a blind relay that cannot read what it is transporting. Most candidates treat this as 'send message, store in DB' and miss everything that makes chat actually work in production.

Premium Access
Sign in

Design Social Graph

Design the social graph infrastructure behind a platform like Facebook or LinkedIn -- the system that stores who is connected to whom and answers graph queries in real time. At 3 billion users and 500 billion friendship edges, this is one of the largest data structures humanity has ever built.

Here's what makes this problem genuinely hard: it is not just storage. You need to answer 'are Alice and Bob friends?' in O(log n), compute their mutual friends in under 50ms, run a 2-hop BFS touching 109K nodes for 'People You May Know' in under 100ms, and handle the power-law distribution where most users have fewer than 200 friends but some have 5,000+. Most candidates reach for a graph database and stop there. The ones who get hired explain why Facebook uses MySQL with a custom caching layer (TAO) instead of Neo4j -- and can articulate exactly why that is the right tradeoff at planetary scale.

Premium Access
Sign in

Design Metrics & Monitoring System

Design a distributed metrics and monitoring system like Datadog, Prometheus, or AWS CloudWatch. The system must ingest millions of metrics per second from instrumented applications, store them efficiently in a time-series database, support flexible queries and dashboards, and trigger alerts based on SLI/SLO thresholds.

Here is the thing about this problem -- it looks straightforward on the surface, but it is actually one of the deepest system design questions you will face. You are not just building a database with a UI. You are building a high-throughput write pipeline that has to handle 10M data points per second, compress them down to something affordable to store, serve sub-second dashboard queries over months of data, and -- most critically -- wake someone up at 3 AM when things go wrong. Most candidates miss the nuance in percentile computation (you cannot average p99 values), the push vs. pull collection tradeoff, and the sheer compression engineering that makes time-series storage feasible. Getting those right is what separates senior candidates.

Premium Access
Sign in

Design Task Queue

Design a distributed task queue system like Celery, Sidekiq, or AWS SQS. Producers submit tasks (jobs) to a queue, and a fleet of workers picks them up and executes them reliably.

Here is the thing about task queues: every backend engineer has used one, but most have never thought deeply about what happens when a worker crashes mid-execution, or when a producer retries after a network timeout and accidentally submits the same job twice. The entire design comes down to one question -- can you explain the difference between at-least-once and exactly-once delivery, and why the industry has settled on at-least-once-plus-idempotency as the practical answer? If you can nail that tradeoff and then show how visibility timeouts, fencing tokens, and dead letter queues work together to make the system bulletproof, you have demonstrated the distributed systems depth interviewers are looking for.

Premium Access
Sign in

Design Video Conferencing

Design a large-scale video conferencing system like Zoom, Google Meet, or Microsoft Teams. This is genuinely one of the hardest system design problems you will encounter, and the most common mistake is treating it like a normal web application.

Here is the thing: the moment you say 'use WebSockets for video,' you have lost the interview. Video conferencing lives in a fundamentally different world from typical request-response systems. You are dealing with UDP-based media that tolerates packet loss but cannot tolerate latency, NAT traversal that requires STUN/TURN servers most engineers have never heard of, and a media routing decision (SFU vs MCU) that determines whether your server fleet costs $1M or $50M per month.

The key architectural insight is that the system is actually *two completely separate systems bolted together*: a signaling plane (lightweight JSON over WebSocket -- a standard web application) and a media plane (encrypted UDP streams forwarded at wire speed -- a real-time networking problem). Getting the boundary between these two planes right, and understanding why they need to be independent, is what separates senior-level answers from textbook ones.

Premium Access
Sign in

Design Key-Value Store

Design a distributed key-value store like AWS DynamoDB, Apache Cassandra, or Riak. The system must store billions of key-value pairs across a cluster of commodity machines, handle 10 million operations per second, and maintain 99.99% availability -- even during node failures, network partitions, and rolling deployments.

Here is the thing about this problem: it is the ultimate CAP theorem question, and the interviewer is testing whether you can reason about the tradeoff *in practice*, not just recite the theory. Every design decision you make -- LSM-tree vs B-tree, AP vs CP, vector clocks vs last-writer-wins -- has real consequences that cascade through the entire system. Most candidates can sketch the consistent hash ring. Strong candidates can explain why virtual nodes fix data distribution skew. The best candidates can walk through what happens during a network partition, why hinted handoff preserves availability, and why tombstones can resurrect deleted data if you are not careful about gc_grace_seconds. That level of depth is what we are aiming for here.

Premium Access
Sign in

Design Collaborative Editor

Design a real-time collaborative document editor like top tech companies Docs or Notion. Multiple users can simultaneously edit the same document, see each other's cursors and selections in real time, and resolve conflicts seamlessly -- even when some users are offline.

Here is why this problem is genuinely hard, and why most candidates underestimate it: it is a distributed consensus problem disguised as a text editor. When Alice types 'Hello' at position 5 and Bob simultaneously deletes characters at position 3, the system must merge both edits so that neither keystroke is lost and all clients converge to an identical document state. That is not a web development problem -- that is a distributed systems theory problem.

The interviewer is testing three things: (1) Do you understand *why* naive approaches fail -- last-write-wins destroys data, locking kills the real-time experience? (2) Can you articulate the difference between OT (Operational Transformation) and CRDTs and make a reasoned choice? (3) Can you separate the real-time hot path (in-memory, zero disk I/O, sub-millisecond) from the durable cold path (operation log, snapshots, S3)? If you can explain the transformation algorithm for a simple insert-vs-insert conflict, you have demonstrated deeper systems thinking than 90% of candidates.

Premium Access
Sign in

Design Pastebin

Let's design a text-sharing service like Pastebin or Hastebin. The idea is straightforward: users paste some text -- code snippets, logs, config files -- get a unique short URL back, and anyone with that URL can view the content with optional syntax highlighting.

What makes this a great interview question is the depth hiding beneath the simplicity. You will need to think about content-addressable storage and deduplication (tons of people paste the same stack traces), how to handle variable-size objects efficiently, and how to implement TTL-based expiration that actually works at scale without eating your storage budget alive.

Premium Access
Sign in

Design Netflix

Let's tackle one of the most comprehensive system design problems out there: designing a video streaming platform like the streaming platform that serves 250M+ subscribers across 190 countries. The system needs to handle video upload and transcoding, adaptive bitrate streaming, a personalized recommendation engine, and a global CDN that accounts for 15% of all downstream internet traffic in the US.

What makes this question so challenging -- and why it is a favorite at senior-level interviews -- is that it spans every layer of the stack. You are dealing with massive storage (petabytes of video), compute-intensive transcoding pipelines, real-time adaptive streaming, machine learning recommendations, and a custom CDN architecture (Open Connect) that physically deploys hardware inside ISP networks. There is no single clever trick that solves it -- you need to reason about each subsystem and how they fit together.

Premium Access
Sign in

Design a major social platform News Feed

Let's design the News Feed for the world's largest social network. When a user opens the app, they see a personalized feed of posts from friends, pages, and groups, all ranked by an ML model that predicts which content they will actually find meaningful.

Here is why this is one of the best system design questions: it is NOT a simple reverse-chronological timeline. It is a full ranking pipeline that evaluates thousands of candidate stories, scores each one across hundreds of features, and returns the top 50 in under 200ms. You need to reason about 3 billion registered users (1 billion DAU), 10,000+ new posts per second, a hybrid fan-out strategy to solve the celebrity problem, real-time content moderation that blocks harmful content before it reaches any feed, and aggregation of related stories ('5 friends liked this').

What separates a strong answer from a mediocre one is getting the ranking architecture right and explaining how it interacts with fan-out, aggregation, and content integrity. Most candidates either ignore ranking entirely or bolt it on as an afterthought -- make it central to your design from the start.

Premium Access
Sign in

Design a Search Engine

Let's design a web-scale search engine. The system crawls the web to discover pages, builds a massive inverted index over 100B+ documents, processes user queries by looking up matching documents and ranking them by relevance, and returns the top 10 results in under 500ms.

This is one of the most complex distributed systems ever built, and it is one of my favorite interview questions because it touches every fundamental concept: distributed storage, MapReduce-style batch processing, inverted indexes, relevance scoring (TF-IDF, BM25, PageRank), caching at multiple layers, and the critical sharding decision (partition by document vs. partition by term). The interview will likely focus on two very different systems -- the indexing pipeline (batch, throughput-optimized) and the query serving path (real-time, latency-optimized). Each has different scaling challenges and failure modes.

The thing that separates a senior answer from a junior one: getting the inverted index design right and being able to articulate the document-vs-term sharding tradeoff with real numbers.

Premium Access
Sign in

Design a Distributed File System

Let's design a distributed file system like GFS or HDFS -- one of the most foundational infrastructure problems in systems design. The system needs to store petabytes of data across thousands of commodity machines, handle very large files (multi-GB to TB), optimize for sequential read/write throughput (batch analytics, MapReduce), and tolerate frequent hardware failures without data loss.

What makes this a great interview question is that it tests your ability to reason about single-master coordination, chunk-based data distribution, replication placement, consistency tradeoffs, and the real operational challenges of running storage at planet scale. The original GFS paper from 2003 and HDFS are the gold standards, and interviewers expect you to know the architecture cold and, more importantly, articulate WHY each design decision was made -- not just describe what the system does.

Premium Access
Sign in

Design a Distributed Logging System

Let's design a distributed logging system -- the kind of infrastructure every engineer uses daily but few understand end to end. The system needs to collect, aggregate, index, and enable searching across logs from thousands of application servers, similar to the ELK stack, Splunk, or Datadog Logs. We are talking ~432 TB of logs per day (10 million events per second at peak, 500 bytes average event size), sub-10-second search latency across petabytes of indexed data, and support for structured queries, full-text search, and log correlation via trace IDs.

Interviewers love this question because it is a bread-and-butter infrastructure problem that tests your ability to design high-throughput data pipelines, make tradeoffs between indexing cost and query speed, and reason about retention policies that balance storage cost with operational needs. The logging system is also the one system that absolutely must work when everything else is broken -- you debug failures by reading logs, so the logging pipeline cannot itself be fragile.

Premium Access
Sign in

Design Analytics Dashboard

Let's design an analytics dashboard platform like Grafana or Datadog Dashboards. Users create dashboards with panels (charts, tables, heatmaps, gauges) that query diverse data sources -- Prometheus, InfluxDB, Elasticsearch, PostgreSQL, CloudWatch -- and render real-time or historical visualizations.

The core challenge that makes this problem interesting is query federation: a single dashboard might query 5 different backends with different query languages, latencies, and data models, and the results need to be unified, transformed, and rendered in under 2 seconds. Layer on 100K+ dashboards viewed concurrently, real-time refresh via WebSocket push at 5-second to 5-minute intervals, multi-tenant isolation with RBAC, and an alerting engine evaluating ~50K rules at 10-60 second intervals (~1,700 evaluations/sec) -- and you have a genuinely complex system.

This is a 'wide and deep' problem that tests whether you can compose many subsystems into a coherent product, rather than just designing one deep component.

Premium Access
Sign in

Design a Config Management System

Let's design the system that every microservice talks to but nobody thinks about until it breaks: centralized configuration management. It needs to serve 100K microservice instances with 1M config reads per second, propagating changes to all clients within 100ms per region (200ms cross-region). This is genuinely the nervous system of a microservices architecture -- every service needs database URLs, feature flags, rate limits, A/B test assignments, and kill switches, and getting any of it wrong can take down your entire fleet.

The system must support hot-reload (change configs without restarting services), feature flags with gradual rollouts, environment hierarchies (dev/staging/prod), a full audit trail, and safe rollback. Think Archaius, Borg config, or LaunchDarkly. What makes this a great interview question is that it touches distributed systems fundamentals (consistency vs. availability, push vs. pull), product thinking (feature flags, rollout strategies), and operational excellence (audit trails, rollback) all in one design.

Premium Access
Sign in

Design Data Pipeline (ETL/ELT System)

Let's design a data pipeline platform -- the kind of infrastructure that Airflow, Fivetran, and dbt collectively provide. The system extracts data from thousands of heterogeneous sources (databases, APIs, event streams), loads it into a central data lake or warehouse, transforms it into analytics-ready tables, and orchestrates the entire workflow as DAGs.

Here is what makes this problem hard: 10,000+ concurrent pipelines processing 1 PB per day, exactly-once semantics for critical financial data (because counting revenue twice is worse than counting it once), schema evolution without breaking downstream consumers, data quality gates that catch bad data before it poisons dashboards, and full column-level lineage from source to dashboard so you can answer 'where did this number come from?'

This is the backbone of every modern data-driven company, and it is a favorite interview question at companies building data infrastructure because it tests both distributed systems depth and product thinking.

Premium Access
Sign in

Design a Distributed Database (Spanner/CockroachDB)

Let's design a globally distributed SQL database like Spanner or CockroachDB -- arguably the most technically ambitious system design problem you can encounter in an interview. The system provides full SQL semantics (joins, indexes, foreign keys, ACID transactions) across a cluster spanning multiple datacenters and continents.

What makes this different from every other distributed system question: instead of sacrificing consistency for availability (the easy path), this system chooses strong consistency -- every read sees the result of the most recent committed write, even across regions. The core challenge is achieving external consistency (stronger than linearizability) while maintaining low-latency reads and writes globally.

You will need to reason about Raft-based consensus for replication, two-phase commit for cross-range transactions, TrueTime or Hybrid Logical Clocks for global ordering, range-based sharding for data distribution, and a distributed SQL query engine that pushes computation close to the data. Each of these is complex individually; making them work together coherently is what earns the senior signal.

Premium Access
Sign in

Design a Distributed Lock Service

Design a distributed lock service that provides mutual exclusion across thousands of distributed nodes at 1M lock acquisitions per second with sub-5ms P99 latency. This is one of those foundational infrastructure problems that shows up everywhere once you start looking — payment systems need it to avoid double-charging, data pipelines need it for exactly-once processing, and leader election in every microservice cluster depends on it.

Here is what makes this problem genuinely hard, and why it trips up so many candidates: the core challenge sounds trivially simple — just make sure only one process holds a lock at any time. But then reality kicks in. Networks partition, clocks drift between machines, processes crash mid-operation, and JVM GC pauses can freeze a thread for hundreds of milliseconds while the rest of the world keeps moving. A naive Redis SETNX breaks under partition because the lock holder might not realize it lost the lock when the partition healed. Redlock tried to fix this with multi-node quorums but Martin Kleppmann wrote a famous critique showing it has subtle safety holes.

ZooKeeper actually gets the correctness right (it is built on ZAB consensus), but it is painfully slow — 10-15ms per lock acquisition, which is a non-starter for hot paths. This question is one of the best litmus tests in system design because it separates engineers who genuinely understand distributed consensus from those who think locking is just a SETNX command.

Premium Access
Sign in

Design Live Streaming Platform

Design a large-scale live streaming platform like Twitch or YouTube Live. This is one of the hardest system design problems you will encounter because it touches every layer of the stack simultaneously: real-time media ingest from hundreds of thousands of concurrent streamers via RTMP/SRT, a massive transcoding farm churning out adaptive bitrate (ABR) renditions in real time, a CDN edge network pushing HLS/DASH segments to tens of millions of concurrent viewers with sub-5-second latency, a chat system that needs to fan out messages to rooms with 100K+ participants at sub-200ms delivery, and a DVR/rewind system that lets viewers seek backward without disrupting the live edge.

The fundamental tension that shapes every decision in this design is latency versus scale. WebRTC gives you sub-second latency, which feels magical, but it simply cannot scale past a few thousand viewers per stream — its peer-to-peer mesh and TURN relay architecture just was not built for broadcast. On the other hand, traditional HLS scales to literally billions of viewers through CDN caching, but it adds 15-30 seconds of delay, which kills the interactive feel for gaming, sports, and auctions. Modern protocols like Low-Latency HLS (LL-HLS) and WebTransport thread the needle between these extremes, and understanding where each fits is what makes this question so rich.

Premium Access
Sign in

Design a Service Registry & Discovery System

Design a service registry and discovery system that tracks 50K service instances across multiple datacenters, handles 10M discovery lookups per second with sub-5ms latency, and self-heals when instances crash or become unhealthy. If you have worked in any microservices environment, you know the pain this solves: Service A needs to find healthy instances of Service B to send requests to, but instances are ephemeral — containers start and stop constantly, auto-scaling adds and removes nodes, and rolling deployments cycle through the entire fleet.

Hard-coding IP addresses is obviously impossible at this scale. A service registry is essentially the phone book of microservices: services register themselves on startup, deregister on graceful shutdown, and other services look them up at runtime. Netflix Eureka, HashiCorp Consul, and AWS Cloud Map are all production implementations of this pattern, each with different tradeoff choices.

What makes this interview question particularly interesting is that it forces you to reason about registration protocols, health checking strategies (should the server poll instances or should instances heartbeat?), discovery patterns (does the client do the lookup or does a proxy?), consistency trade-offs (do you want an AP registry that is always available but might serve slightly stale data, or a CP registry that is always correct but might reject requests during partitions?), and the critical failure modes that can cascade a registry outage into a fleet-wide meltdown where nothing can find anything.

Premium Access
Sign in

Design Recommendation System

Design a large-scale recommendation system like Netflix's movie suggestions, Spotify's Discover Weekly, or TikTok's For You Page. The system needs to serve personalized recommendations to 500M+ users across 100M+ items with sub-200ms latency — and get better at it every day.

What makes this one of the most impactful system design questions at ML-heavy companies is that it forces you to think about the full stack of a real-time ML system, not just the model. You need to reason about the two-stage candidate generation and ranking pipeline (because scoring 100M items per request is computationally impossible), feature engineering with online and offline stores (because the model needs both historical signals and real-time context), model serving infrastructure (because a 200ms latency budget leaves almost no room for complex inference), cold-start strategies (because new users and new items have no interaction data to work with), and the exploration-exploitation tradeoff (because always recommending safe picks means you never discover that a user secretly loves jazz). These are the core challenges behind every modern recommendation engine, and understanding the tradeoffs between them is what separates a strong answer from a textbook one.

Premium Access
Sign in

Design a Time-Series Database

Design a time-series database (TSDB) optimized for storing, compressing, and querying timestamped metric data — the kind of data that every engineering team generates but few think deeply about: infrastructure monitoring (CPU usage, request latency), IoT sensors (temperature, pressure readings every second), financial markets (stock prices and trade volumes at millisecond granularity), and application telemetry (events, counters, histograms).

What makes a TSDB fundamentally different from a general-purpose database like PostgreSQL is the workload shape. Writes are massive and append-only — you are inserting millions of data points per second and you almost never update or delete individual rows. Reads are almost always time-range scans — 'give me the average CPU across 500 servers for the last 24 hours.' And data has a natural lifecycle — yesterday's per-second data is valuable, but last year's per-second data is just expensive storage; you want to automatically downsample it to per-hour aggregates.

The core engineering challenge is designing a storage engine that is simultaneously write-optimized (leveraging the sequential, append-only nature of time-series writes) and read-optimized (using columnar layout and time-aware compression to achieve 10-16x compression ratios while keeping time-range queries fast). On top of that, you have to handle the 'cardinality explosion' problem: in a large monitoring system, the number of unique metric series (the cross-product of host x metric x tag combinations) can reach tens of millions, which stresses both memory for indexing and disk for storage.

Premium Access
Sign in

Design a Data Warehouse (Snowflake/BigQuery)

Design a cloud-native data warehouse that can store petabytes of structured data and execute complex analytical queries — joins across billion-row tables, multi-dimensional aggregations, window functions — in seconds to minutes. If you have used Snowflake, BigQuery, or Redshift, you know the user experience we are targeting: an analyst writes SQL, hits run, and gets results across terabytes of data in under a minute.

The fundamental insight that shapes this entire design is how different analytical workloads are from transactional ones. An OLTP database like PostgreSQL is optimized for single-row reads and writes — find one customer, update their balance. A data warehouse does the opposite: it scans millions of rows but typically reads only a handful of columns at a time. That workload shape drives us toward columnar storage, where storing each column contiguously on disk means a query reading 3 of 50 columns only touches 6% of the data.

The revolutionary architectural idea here is compute-storage separation, which Snowflake pioneered. Data lives in cheap, durable cloud object storage (S3/GCS), and computation is provided by elastic virtual warehouse clusters that can be created, resized, and destroyed independently. This separation is what enables you to run 10 concurrent analytical workloads on the same dataset without them stepping on each other, scale compute up for a heavy ad-hoc query and back down to zero when the analyst goes to lunch, and pay only for compute you actually use. You will design a columnar storage layer, an MPP query engine, an ETL/ELT ingestion pipeline, and a multi-tenant resource management system.

Premium Access
Sign in

Design Real-Time Stream Processing System

Design a distributed real-time stream processing system like Apache Flink, Kafka Streams, or Apache Storm — a platform that continuously processes millions of events per second with sub-second latency. Unlike batch processing where you have the luxury of seeing all your data before computing a result, stream processing requires you to produce answers incrementally as data arrives, handle late data gracefully, and maintain correctness through failures — all simultaneously.

Core capabilities you need to nail:
• Stateful aggregations over time windows (tumbling, sliding, session) — because most useful stream computations accumulate state over time
• Exactly-once processing semantics — because 'at-least-once' means duplicate charges in a payment pipeline
• Late-arriving data handling via watermarks — because mobile events routinely arrive minutes after they occurred
• Distributed state with checkpointing for fault tolerance — because you cannot afford to reprocess hours of data after a crash
• Backpressure propagation when downstream systems are slow — because the alternative is buffering until you OOM

Why this matters in practice: This is the engine behind Uber's real-time pricing, Netflix's per-title viewing analytics, LinkedIn's activity feeds, and every fraud detection system processing credit card transactions in real time. It is one of the most technically demanding system design questions because it requires simultaneously reasoning about distributed systems, time semantics (event time vs. processing time is not a theoretical distinction — it determines whether your results are correct), and fault tolerance under continuous, never-ending processing.

Premium Access
Sign in

Design Gaming Platform

Design the backend infrastructure for a competitive online multiplayer game like League of Legends, Fortnite, Valorant, or Overwatch. This might be the most technically demanding system design problem on the list because it combines so many hard sub-problems, each of which could be its own interview question: a matchmaking system that must find balanced matches for millions of concurrent players in under 30 seconds, a tick-based game server architecture running at 60-128Hz where every single millisecond of latency is felt by players, an authoritative server model where the server is the single source of truth (because if the client is trusted, people will cheat), lag compensation techniques (client-side prediction, server reconciliation, entity interpolation) that make the game feel responsive even though packets take 20-100ms to cross the network, a global leaderboard serving real-time rankings across millions of players, an inventory and economy system managing billions of virtual item transactions with ACID guarantees, and an anti-cheat system that catches cheaters without punishing legitimate players with false positives.

The core tension that runs through every design decision: the game must feel instantaneous and responsive to every individual player, while the server enforces a single, consistent, cheat-proof world state across all participants. Those two goals are fundamentally in conflict with each other when you have non-zero network latency, and the clever tricks used to bridge that gap (prediction, reconciliation, interpolation) are what make game networking one of the most fascinating areas of distributed systems.

Premium Access
Sign in

Design Analytics Platform (Mixpanel / Amplitude)

Design a product analytics platform like Mixpanel or Amplitude — the kind of system where a product manager can ask 'what percentage of users who viewed a product also purchased it, broken down by country?' and get an answer in a few seconds, even though the query is scanning billions of events under the hood.

The system ingests billions of user behavior events per day (page views, button clicks, purchases, feature usage) and lets product teams slice this data in real time across arbitrary dimensions: funnels ('View Product -> Add to Cart -> Purchase, what is the conversion rate at each step?'), retention ('of users who signed up in January, how many came back each subsequent week?'), cohort analysis ('how do users who completed onboarding compare to those who skipped it?'), and segmentation ('break down purchases by country, device, and plan type'). The power of the product comes from the arbitrary-dimension part — users do not know in advance which questions they will ask, so you cannot pre-compute everything.

The core engineering challenge is making these complex analytical queries fast (sub-10-second response times) across 100B+ events/day while simultaneously providing strict multi-tenant data isolation (one customer must never see another's data) and handling flexible schema evolution (events have arbitrary user-defined properties that change without warning).

Premium Access
Sign in

Design Search System (Internal / App Search)

Design an internal search system that powers product search for an e-commerce platform, listing search for a marketplace, or document search for a SaaS application. Think about what happens when a user types 'wireles headpones' into a search bar — the system needs to understand they meant 'wireless headphones' (typo tolerance), show them relevant results ranked by a mix of text relevance and business signals like popularity and freshness, let them filter by category, price range, and brand with instant facet counts, and do all of this in under 100ms so the results feel instantaneous.

The system must support full-text search with typo tolerance, faceted filtering, relevance tuning (every tenant wants to boost different signals — an e-commerce site boosts popular products, a job board boosts recent postings), multi-tenant index isolation (10K+ tenants sharing infrastructure without seeing each other's data), and autocomplete that returns suggestions on every keystroke in under 50ms. All of this at 50K queries/sec with sub-100ms P95 latency. This is the kind of search that Algolia, Elasticsearch, and Typesense power for thousands of applications, and understanding the internals — inverted indexes, BM25 scoring, roaring bitmaps for facets — is what makes this a strong system design question.

Premium Access
Sign in
Student? Ping us for a discount!