System design interview questions ask you to design a large system, such as a URL shortener, a chat app or a payment ledger, in 45 to 60 minutes on a whiteboard. The 18 below are the ones that come up most. Each has what the interviewer is testing, the requirements to clarify, the numbers to estimate, a core design with a diagram, the deep dives to offer and the mistakes to avoid. Answer every one with the same six steps: requirements, estimates, API and data, high-level design, deep dives and wrap up.
In the order of the OphyAI practice library, from the starter question to the advanced ones. Each name jumps to its full answer.
| # | Question | Core idea | Level | Mock round |
|---|---|---|---|---|
| 1 | URL shortener | Unique short codes and a read path built for caching | Starter | 35 min |
| 2 | Rate limiter for a public API | Token buckets, atomic counters and limits across regions | Core | 45 min |
| 3 | News feed | Fan-out on write vs read, and accounts with millions of followers | Core | 45 min |
| 4 | Chat app | Persistent connections, ordering, delivery receipts and presence | Core | 45 min |
| 5 | Ride-hailing dispatch | A geo index under heavy writes, and matching without double booking | Advanced | 60 min |
| 6 | Payment ledger | Idempotency, a double-entry ledger and reconciliation | Advanced | 60 min |
| 7 | Video upload and streaming | Chunked uploads, a transcoding pipeline and CDN delivery | Advanced | 60 min |
| 8 | Web crawler | The URL frontier, politeness per host, and dedupe | Core | 45 min |
| 9 | Notification system | Queues per channel and priority, retries and user preferences | Core | 45 min |
| 10 | Search autocomplete | A prefix index with precomputed top results, at very low latency | Core | 45 min |
| 11 | File storage and sync | Chunking, dedupe, delta sync and conflicts | Advanced | 60 min |
| 12 | Ticket booking with seat holds | Seat holds that expire, and surviving on-sale spikes | Core | 45 min |
| 13 | Real-time leaderboard | Sorted sets, rank queries and sharding | Core | 45 min |
| 14 | Hotel reservations | Inventory per night, the last room, and safe retries | Core | 45 min |
| 15 | Food delivery tracking | An order state machine, dispatch timing and a live ETA | Advanced | 60 min |
| 16 | Distributed cache | Consistent hashing, hot keys and staying in step with the database | Advanced | 60 min |
| 17 | Metrics and alerting | Time-series ingest, downsampling and alerting that keeps working | Advanced | 60 min |
| 18 | Ad click aggregator | Stream windows, exactly-once counts and late events | Advanced | 60 min |
Use the same six steps every time. The minutes are targets for a 45 or a 60 minute round. They are a guide, not a rule.
Ask who uses it, the 3 to 5 features that matter most, the scale, and the goals for latency, availability and consistency. Write them on the board and say what is out of scope.
"So: create and redirect, 100M new links a day, redirects under 50 ms, and analytics can lag a few minutes. Custom domains are out of scope. Does that match what you had in mind?"
Size reads and writes per second, storage and bandwidth, on average and at peak. Round hard. Then say what the numbers mean for the design.
"120k reads a second is 100 times the writes, so the read path gets a cache, and 90 TB over 5 years means the store has to be sharded."
How to estimate QPS, storage and bandwidthWrite the main endpoints with their key parameters, and the core tables or key-value schemas with their keys. Pick the store from how the data is read.
"Every redirect is a lookup by code, so a key-value store keyed by code fits better than joins in a relational database."
Draw the main boxes and arrows for each core flow and walk one request from the client to storage and back. Make it work before you make it scale.
"A redirect hits the load balancer, then the redirect service, which checks the cache and falls back to the store on a miss."
Go deep on the 2 or 3 hardest parts: bottlenecks, consistency, hot spots and failures. Offer one yourself by about two thirds of the round, and name the trade-off of each choice.
"The riskiest part is generating unique codes across many servers. Can I walk through two ways to do it and pick one?"
Recap the design against the requirements, name the trade-offs you made, and say what you would do next with more time: monitoring, cost, and what breaks at 10x.
"We trade a little analytics freshness for fast redirects. At 10x, I would add a CDN for viral links and split analytics into its own pipeline."
Each answer follows the six steps. The numbers are rounded estimates for the stated assumptions, which is exactly how you should present them in the room.
Solid arrows are requests. Dashed arrows are background or async work. Boxes with a line under the top are databases, boxes with three ticks are queues or logs, and gray boxes are clients and outside services.
Every estimate uses 86,400 seconds in a day and decimal units. Try your own numbers in the back of the envelope estimator.
All 18 are mock rounds in OphyAI System Design, on the Premium plan at 20 credits a round. Already a member? Open System Design.
Design a service that turns long links into short codes and redirects people who open them, at a high read volume.
Also asked as: Design a URL shortener · Design TinyURL · URL shortening service
Whether you can run the whole framework cleanly on a simple problem: a tidy API, a key scheme that never collides, and a read path built for caching. It is a starter question, so the bar is a complete, well-reasoned answer, not exotic tricks.
New to estimates? How to do a back of the envelope calculation
Hashing the long URL (say MD5, keep 7 characters) needs a collision check and a retry, and the same URL always gets the same code. A counter never collides: each Shorten node leases a block of IDs, say 1,000 at a time, from a database sequence or a coordinator, then base62-encodes them. Counter codes are easy to guess; if that matters, scramble the ID with a reversible permutation before encoding. Custom aliases use a conditional write (insert only if absent).
Clicks follow a power law, so caching the most-clicked links catches most reads. If 20M links get most traffic, that is 20M × 500 bytes ≈ 10 GB, which fits in memory with room to spare. Use cache-aside with a TTL and LRU eviction, and put a CDN in front for viral links. A 301 is cached by browsers, which saves load but hides repeat clicks from analytics; a 302 keeps every click visible.
Store expires_at and check it on every read, so an expired link stops working right away even before cleanup. A background sweep deletes expired rows later to free space. Do not hand out expired codes again soon, or old links in emails and docs will point to someone else's page.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a rate limiter for a public API that enforces per-customer limits across many servers and regions.
Also asked as: Design a rate limiter · API rate limiting · Distributed rate limiter
Your choice of algorithm and its trade-offs, atomic counters under concurrency, where the limiter sits in the request path, and what happens when the limiter itself fails. Strong answers keep the added latency to a couple of milliseconds.
New to estimates? How to do a back of the envelope calculation
Name the options, then pick one for this API and say why. For a public API that should allow short bursts, a token bucket per key is a strong default.
| Algorithm | How it works | Trade-off |
|---|---|---|
| Fixed window counter | One counter per key per minute, reset at the boundary. | Cheapest, but allows up to 2x the limit around a window edge. |
| Sliding window log | Store each request time in a sorted set and count the last N seconds. | Exact, but memory grows with traffic. |
| Sliding window counter | Weight the previous window's count by how much it overlaps the current one. | Close to exact with two counters per key. |
| Token bucket | Tokens refill at a steady rate up to a cap; each request takes one. | Allows controlled bursts with two fields per key. |
| Leaky bucket | Requests queue and drain at a fixed rate. | Smooth output, but adds delay under load. |
The classic bug: two servers both read "1 token left" and both allow the request. Do the refill, check and decrement in one atomic step, such as a Lua script in Redis, or INCR plus EXPIRE for a fixed window. Never read, decide and write back from the app server in separate calls.
One global counter adds a cross-region round trip to every request. Instead give each region a share of the limit and sync usage in the background, accepting a small overshoot. If the counter store is down, fail open with a rough in-memory limit per server for most endpoints, and fail closed for abuse-prone ones such as login.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign the home feed of a social network, where people see recent posts from the accounts they follow.
Also asked as: Design a news feed · Design the Twitter timeline · Design the Facebook news feed
Fan-out on write versus fan-out on read, the celebrity problem, caching a precomputed feed, and pagination. Interviewers want to see you land on a hybrid and explain exactly why.
New to estimates? How to do a back of the envelope calculation
This is the heart of the question. Push for normal accounts, pull for very large ones, and merge the two at read time. Skip pushing to users who have not opened the app in weeks; rebuild their feed if they come back.
| Strategy | Reads | Writes | Best for |
|---|---|---|---|
| Fan-out on write (push) | One cache lookup | One write per follower | Normal accounts |
| Fan-out on read (pull) | Merge many authors at read time | One write | Accounts with millions of followers |
| Hybrid | Cache lookup plus a few pulls | Push only below a follower threshold | The usual answer |
Split it into candidate generation (recent ids from the feed cache plus pulled posts from big accounts) and a ranking step that scores a few hundred candidates with precomputed features. Keep a chronological fallback if ranking is slow or down.
Page with a cursor on the post id or time, not an offset: new posts shift offsets and cause repeats or gaps. If a user's feed list was evicted, rebuild it on demand from the accounts they follow and write it back to the cache.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a chat app with one-to-one and group conversations, delivery receipts and online presence.
Also asked as: Design WhatsApp · Design Messenger · Design a chat system
Long-lived connections at scale, how a message finds the server that holds the recipient's connection, ordering within a conversation, delivery guarantees, and what happens when someone is offline.
New to estimates? How to do a back of the envelope calculation
Phone clocks drift, so never order by the sender's timestamp. The chat service assigns a sequence number per conversation (a counter stored with the conversation, or an atomic increment). Clients sort by it and can spot a gap and fetch what they missed.
Aim for at-least-once delivery with dedupe. The sender retries until the server acks, and the client-made message id lets everyone drop duplicates. Delivered and read are acks flowing back: store last_delivered_seq and last_read_seq per member instead of a row per message per reader.
For a group of thousands, fan out by gateway, not by person: send one copy to each gateway that holds members, and let it deliver locally. Offline members get a push notification, then sync from their last sequence number when they reconnect.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign the dispatch system for a ride-hailing app that matches riders to nearby drivers and tracks each trip live.
Also asked as: Design Uber · Design Lyft · Design a ride-sharing service
A geospatial index that takes a flood of location updates, matching a rider to a driver without double booking, live trip tracking, and sharding by geography.
New to estimates? How to do a back of the envelope calculation
Geohash cells are string prefixes: easy to shard and look up, but a rider near a cell edge needs the 8 neighbor cells too. Quadtrees adapt to density but are costly to update 250k times a second. Hexagon grids such as H3 have even neighbor distances. With this write rate, a simple in-memory map from cell to drivers works well: move a driver between cells on each ping and drop entries that have not updated in, say, 30 seconds. Widen the search ring if too few drivers come back.
Offer each ride to one driver at a time, with a short timeout (10 to 15 seconds). Claim the driver atomically: set status from available to offered only if it is still available, using SET NX with a TTL in Redis or UPDATE ... WHERE status = 'available' AND version = n. The TTL frees the driver if they never answer.
Shard the geo index and matching by city or region, since a ride almost never crosses regions. Airports and stadiums are hot cells with long lines of drivers; give them a first-in, first-out queue instead of a nearest-driver search.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a payment system with a ledger that charges cards, never loses or double counts money, and reconciles with the payment processor.
Also asked as: Design a payment system · Design a digital wallet · Design a ledger service
Correctness over raw speed: idempotent retries, double-entry accounting, side effects that happen exactly once (the outbox pattern), and reconciliation with an outside payment processor.
New to estimates? How to do a back of the envelope calculation
The client sends an Idempotency-Key header. Store the key, a hash of the request body, the status and the response in the same database as the payment, under a unique constraint. A retry with the same key gets the stored response; the same key with a different body is an error. Send your own idempotency key to the PSP too, so a timeout on your side can be retried without charging twice.
Every transaction is a set of entries that sum to zero: for a $100 charge with a $3 fee, debit customer funds 100, credit the merchant 97 and credit fees 3. Entries are never updated or deleted; a refund or a fix is a new transaction. Balances come from entries (or a cached balance updated in the same transaction), so the books can always be rebuilt and checked.
You cannot commit to a database and publish to a message stream in one atomic step. Write an outbox row in the same transaction, have a relay publish it, and make consumers dedupe by event id. Every day, match the ledger against the PSP's settlement file; fix each mismatch with an adjusting entry, never by editing history.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a video platform where creators upload videos and viewers stream them smoothly on any device.
Also asked as: Design YouTube · Design Netflix · Design a video streaming platform
Keeping the upload and processing pipeline separate from playback, transcoding at scale, adaptive bitrate streaming, and showing with numbers why playback must come from a CDN.
New to estimates? How to do a back of the envelope calculation
A 4 GB upload over a phone connection will drop. Split the file into parts (say 8 to 16 MB) and upload each to its own presigned URL. The client remembers which parts finished and resumes from there. Your API servers never touch the video bytes.
Transcoding a long 4K video in one job takes far too long. Split the source at keyframes, transcode the chunks in parallel across workers, then join them. Model the work as a small graph of steps (check, transcode each rendition, thumbnails, captions) on a queue with retries, and make every step safe to run twice.
Each rendition is cut into 2 to 10 second segments listed in an HLS or DASH manifest. The player measures its throughput and switches rendition between segments, so playback adapts instead of stalling. Popular videos stay hot at the edge; even at a 99% CDN hit rate, origin still sends about 1% of 500 Tbps, which is why the origin tier is spread across regions.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a web crawler that downloads about a billion pages a month for a search index while staying polite to every site.
Also asked as: Design a web crawler · Design a distributed crawler · Design a search engine crawler
The URL frontier, politeness per host, deduplication of both URLs and content, avoiding crawler traps, and how you spread the work over many machines.
New to estimates? How to do a back of the envelope calculation
Front queues order URLs by priority, such as page importance and how stale they are. Back queues each hold one host. A heap keyed by "next time this host may be fetched" tells a free fetcher which back queue to take, which enforces about one request a second per host without slowing other hosts. Cache and obey robots.txt per host.
Normalize URLs before the seen check: lowercase the host, drop fragments and tracking parameters, sort query parameters. Mirrors and copies have different URLs but nearly the same content, so fingerprint pages with SimHash and treat a small Hamming distance as a duplicate.
Calendars and endless filter pages create infinite URLs. Cap depth, URL length and pages per host, and watch for repeating path patterns. Recrawl based on how often a page changed before: a news home page hourly, an old doc page monthly.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a notification system that sends push, email and SMS for many internal services, with user preferences and retries.
Also asked as: Design a notification service · Design a push notification system · Design an email and SMS service
Decoupling with queues, keeping urgent messages away from bulk ones, outside providers that rate-limit and fail, sending each notification once, and respecting user preferences.
New to estimates? How to do a back of the envelope calculation
Producers retry and queues deliver at least once, so duplicates will happen unless you stop them. Each notification carries an idempotency key, and the worker records it in the delivery log with a conditional insert before calling the provider. A crash between sending and recording can still double-send, so keep that window small and pass the provider an idempotency key where it supports one.
Login codes and security alerts get their own queues and workers, so a marketing blast never delays them. Workers respect each provider's rate limit and a per-user cap, such as no more than a few marketing messages a day.
Retry with exponential backoff and jitter, and move a message to a dead-letter queue when its retry window ends. Keep a second provider per channel and switch when error rates climb. Treat "invalid token" errors from push providers as a signal to delete stale device tokens.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign search autocomplete that suggests the top queries as someone types, for a search engine with billions of searches a day.
Also asked as: Design typeahead · Design search suggestions · Design an autocomplete system
A prefix index with the top results precomputed, very low latency at a very high read rate, and a pipeline that rebuilds the index offline while still catching trending queries.
New to estimates? How to do a back of the envelope calculation
Walking the trie below a short prefix such as "a" at request time is far too slow. Store the top 10 completions at every node, computed offline, so a lookup costs only the length of the prefix. Rebuild hourly or daily and swap snapshots in one step, so serving never waits on writes.
A batch index misses breaking news. Run a small streaming job over the last 10 to 60 minutes of queries and merge its top results with the batch list, weighted by a decay factor. Filter everything through a blocklist before it is served.
Shard by prefix range, but not by first letter alone: "s" is far bigger than "x". Split ranges by real traffic. One and two character prefixes are the hottest and change slowly, so cache them at the edge with a short TTL.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a file storage and sync service that keeps a person's files in sync across all their devices.
Also asked as: Design Dropbox · Design Google Drive · Design a file sync service
Keeping file bytes (blocks) apart from metadata, chunking and dedupe, uploading only what changed, handling conflicting edits, and telling other devices about changes quickly.
New to estimates? How to do a back of the envelope calculation
Fixed 4 MB blocks are simple, but inserting one byte near the start shifts every block after it. Content-defined chunking uses a rolling hash to pick block boundaries from the data itself, so an edit changes only a block or two. The client sends block hashes, the server replies with the ones it lacks, and only those upload.
Each commit names the version it was based on. If the server already has a newer version, the commit is rejected, and the client saves a "conflicted copy" instead of overwriting. Last writer wins quietly loses someone's work, which is a common wrong answer.
Upload blocks first, then commit the metadata that points to them, so no file ever points to a missing block. Blocks that nothing points to (failed uploads, versions past retention) are cleaned up later by reference counts or a mark-and-sweep job.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a ticketing system for big concerts where fans pick seats, hold them for a few minutes and pay, during huge on-sale spikes.
Also asked as: Design Ticketmaster · Design a ticket booking system · Design a concert ticketing system
Correctness under contention (no seat sold twice), seat holds that expire on time, and surviving an on-sale spike far above normal traffic, usually with a waiting room.
New to estimates? How to do a back of the envelope calculation
Hold a seat in one atomic step: UPDATE seats SET status = 'held', held_by = ?, hold_expires_at = now() + 10 min WHERE seat_id = ? AND (status = 'available' OR (status = 'held' AND hold_expires_at < now())). Only one request can win. Confirm the sale the same way: UPDATE ... SET status = 'sold' WHERE status = 'held' AND held_by = ?. Redis SET NX with a TTL can sit in front as a fast gate, but the database row decides.
Expiry must work even if no cleanup job runs. Store hold_expires_at and treat an expired hold as available in every query, like the WHERE clause above; a sweeper only tidies rows and refreshes the seat map. Extend the hold briefly when payment starts, so nobody loses a seat mid-payment, and refund automatically if a payment lands after the seat was resold.
Put fans in a queue before they reach the booking service, and admit them in batches at the rate checkout can handle. The admission token is signed and short-lived, so the booking service rejects anyone without one at almost no cost. Add bot checks before admission and limit tickets per account and per card.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a real-time leaderboard for an online game with tens of millions of players that shows the top players and each player's rank.
Also asked as: Design a gaming leaderboard · Design a top-K leaderboard · Design a real-time ranking system
Sorted sets and their costs, rank queries on huge boards, sharding when one node is not enough, daily and weekly boards, and keeping scores honest.
New to estimates? How to do a back of the envelope calculation
One sorted set handles tens of millions of players. Beyond one node, shard by score range: shard 1 holds the highest scores, and so on. A player's global rank is their rank inside their shard plus the size of every higher shard (ZCARD is O(1)). Rebalance the ranges as scores drift. For the long tail, a rough percentile ("top 12%") is often enough and far cheaper.
Use one key per window, such as lb:daily:2026-11-06 and lb:weekly:2026-W45, with a TTL a bit past the window's end. Each score update writes to every active window. If Redis loses a board, rebuild it from the durable score history.
Sorted sets break ties by member name, which is not fair. Fold time into the score, for example points × 10^10 + (a far-future timestamp - the time the score was reached), so whoever got there first ranks higher. Keep the result under 2^53, because Redis stores scores as doubles. Only game servers may submit scores.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a hotel reservation system where guests search by dates and book rooms without overselling.
Also asked as: Design a hotel reservation system · Design a hotel booking system · Design Airbnb bookings
Modeling inventory per room type per night, concurrency on the last room, safe reserve-and-pay retries, and a read-heavy search path that may be a little stale while booking may not.
New to estimates? How to do a back of the envelope calculation
Two guests try to book the last room for the same nights. In one transaction run UPDATE room_type_inventory SET total_reserved = total_reserved + 1 WHERE hotel_id = ? AND room_type_id = ? AND date >= check_in AND date < check_out AND total_reserved < total_rooms (times 1.05 if the hotel allows 5% overbooking). If fewer rows changed than the stay has nights, roll back. Optimistic locking with a version column also works and suits low contention.
The client creates the reservation id when the booking page loads, so a double click or a retry maps to the same reservation. A reservation moves from pending (rooms held) to confirmed (paid) or expired (released by a timeout). The payment call carries its own idempotency key.
Search may show a room that just sold. That is fine as long as booking re-checks the source of truth. Feed the availability index from booking events, and cache popular city and date searches for a short time.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a food delivery service that takes orders, dispatches couriers and shows customers live tracking with an ETA.
Also asked as: Design DoorDash · Design Uber Eats · Design a food delivery app
An order state machine shared by three apps, sending the courier so they arrive when the food is ready, a heavy stream of location updates, and handling failures without stuck orders.
New to estimates? How to do a back of the envelope calculation
Send a courier the moment an order is placed and they wait at the restaurant; send one too late and the food goes cold. Estimate prep time from the restaurant's history and how busy it is now, add travel time, and assign so the courier arrives near the ready time. Batching two orders from nearby restaurants saves courier time, but only if neither ETA slips past its promise.
placed → accepted → preparing → ready → picked_up → delivered, plus cancelled and failed. Apply only allowed moves, each keyed by an event id, with UPDATE ... WHERE status = expected, so a retried event does nothing. This is what keeps three apps from disagreeing about one order.
A courier goes offline, a restaurant never accepts, a customer is not home. Put a timeout on each state that triggers an action: reassign the courier, cancel and refund, or alert support. Keep every transition, so support can see exactly what happened.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a distributed in-memory cache that many services share.
Also asked as: Design a distributed cache · Design Memcached · Design a distributed key-value cache
Partitioning with consistent hashing, replication and failover, eviction, hot keys, and keeping the cache consistent with the database. Also knowing when a cache is the wrong tool.
New to estimates? How to do a back of the envelope calculation
With hash(key) mod N, adding one node remaps almost every key, the cache goes cold and the database gets flooded. On a hash ring, a key belongs to the next node clockwise, so adding or removing a node moves only about 1/N of the keys. Give each server 100 to 200 virtual nodes so load spreads evenly and a failed node's keys land on many servers, not one.
One viral key can overload one node however good the hashing is. Spot hot keys by sampling in the client, then keep them in a tiny local cache for a second or two, or copy them under several suffixed keys (key#1 to key#8) and read one at random.
Cache-aside is the default: read the cache, and on a miss read the database and fill the cache. On a write, update the database, then delete the cache key; deleting is safer than updating, which can race and leave old data. TTLs are the backstop. When a hot key expires, thousands of requests miss at once (a thundering herd); a lease lets one request refill it while the others wait or get the old value.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign a metrics and alerting platform that collects metrics from a million hosts, draws dashboards and pages on-call engineers.
Also asked as: Design a metrics monitoring system · Design a monitoring and alerting system · Design a time-series database
A write-heavy time-series pipeline, storage layout and compression, downsampling for long retention, control of series cardinality, and alerting that still works when ingest is struggling.
New to estimates? How to do a back of the envelope calculation
Hash the metric name plus its sorted tags into a series id. Points for a series arrive in time order, so buffer each series in memory for an hour or two, compress it, then write immutable blocks partitioned by time. A write-ahead log protects what is still in memory. Queries use an inverted index from tags to series ids.
One bad tag, such as a user id or request id, can turn one series into millions and take the store down. Cap new series per team and per metric, drop or reject unbounded tags at ingest, and show teams their own series counts.
Alerts matter most when things are breaking, which is exactly when ingest lags. Give the evaluator its own path and treat missing data as an alert in itself. Require a condition to hold for a while before firing, to stop flapping, and group and dedupe notifications so on-call gets one page, not 500.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionDesign an ad click aggregator that counts clicks per ad per minute for billing and dashboards, without losing or double counting clicks.
Also asked as: Design an ad click aggregator · Design ad click event aggregation · Design real-time click counting
Stream processing with time windows, counts that are exact enough to bill on, late and duplicate events, hot keys, and a batch path that checks and corrects the stream.
New to estimates? How to do a back of the envelope calculation
The log delivers at least once, and the click service may retry. Give each click a unique id at the edge and dedupe in the stream job, keeping seen ids in keyed state a little longer than the lateness window. Checkpoints save that state together with the log offsets, and results are written idempotently (upsert by ad_id and minute), so a restart replays without double counting. At peak, 10 minutes of ids is 500k × 600 ≈ 300M ids, about 5 GB at 16 bytes each, spread across the job.
Window by event time, not arrival time. A watermark tracks how far event time has moved; a window closes once the watermark passes its end plus the allowed lateness (say 5 minutes). Events later than that go to a side output, and the daily batch recount folds them in.
A big campaign can send a large share of all clicks to one key and swamp one partition. Salt the key (ad_id#0 to ad_id#15) to spread it over partitions, count each part, then merge the partial counts. Or pre-aggregate for a second in the click service before sending.
Draw it on a whiteboard while a voice AI interviewer asks follow-ups about your board, then get a Scorecard.
Practice this questionThe parts you will reach for in almost every answer, when each one fits, and the catch to mention before the interviewer does.
| Building block | Use it when | Watch out for |
|---|---|---|
| Load balancer | Spread traffic over stateless servers. Layer 4 for raw connections such as WebSockets; layer 7 to route by path or header. | Sticky sessions hide state in servers. Use health checks and drain connections during deploys. |
| CDN | Static files, images, video segments and cacheable responses, served close to users. | Purging is slow, so put a version in file names. Be careful with per-user data. |
| Cache | Reads far outnumber writes and a small hot set gets most traffic. Cache-aside is the default. | Stale data, hot keys, and herds of misses when a hot key expires. Delete on write and set TTLs. |
| Message queue or log | Decouple slow work, absorb spikes and fan out events. A log such as Kafka when you need order per key and replay. | Delivery is at least once, so consumers must be idempotent. Watch consumer lag. |
| Sharding | Data or writes no longer fit on one machine. Hash for an even spread, range for scans, geography for locality. | Hot shards, queries that span shards, and resharding. Consistent hashing limits how much data moves. |
| Replication | Survive machine loss and scale reads. Leader and followers is the default; multi-leader or leaderless for writes in many regions. | Replica lag: a read right after a write can be stale. Async failover can lose the latest writes. |
| Consistency choices | Strong consistency for money, inventory and anything unique. Eventual consistency for feeds, counters and analytics. | During a network partition you pick consistency or availability (CAP). In leaderless stores, R + W > N gives overlapping quorums. |
| SQL or NoSQL | SQL for relations, transactions and flexible queries. Key-value or wide-column stores for huge scale with simple access by key. | Choose from the access pattern, not fashion. Both kinds can be sharded. |
| Object storage | Large files: photos, video, backups and logs. Cheap and durable; serve it through a CDN. | Not for small, frequent updates. Use presigned URLs so clients upload directly. |
| Rate limiting | Protect services from abuse and overload. A token bucket per key at the gateway is the usual answer. | Counters must be atomic in a shared store. Decide whether to fail open or closed. |
| Idempotency | Any retried write that must happen once: payments, orders, bookings, notifications. | Store the key and the result in the same transaction as the write, and keep keys for a set window. |
| Search index | Full-text search, filters and ranking across many fields. | It is not the source of truth. Feed it from the main store with events or change data capture. |
| Real-time push | Chat, live tracking, notifications and live dashboards, over WebSockets, server-sent events or long polling. | Connections are stateful, so you need a registry of which server holds each user. |
| Unique IDs | Time-sortable IDs (timestamp, machine id and a sequence) for posts, messages and events. | Clock skew between machines. Auto-increment does not work across shards. |
| Bloom filter | Cheap "have I seen this before?" checks, such as crawled URLs. | False positives are possible, false negatives are not. A plain one cannot delete. |
| Geo index | Find things near a point: drivers, couriers, stores. Geohash, quadtree or hexagon cells. | Search neighboring cells too, and use smaller cells where it is dense. |
| Outbox or change data capture | Publish an event reliably after a database write, without a two-system commit. | Consumers must dedupe by event id. |
The full list, with powers of two and latency numbers, is in our back of the envelope calculation guide.
An hour or two a day is enough. Practice out loud and against a timer, because the round tests how you explain as much as what you know.
Week 1: the building blocks, the six steps, daily estimates, and six core questions (URL shortener, rate limiter, news feed, chat app, notification system, ticket booking). Week 2: four advanced questions (payment ledger, ride-hailing dispatch, distributed cache, ad click aggregator) and three or four full mock rounds.
OphyAI System Design helps in the real system design round and in practice: a Live Copilot that tells you what to say and draw next, and full mock rounds on a whiteboard with a voice AI interviewer and a scorecard.
A Mock round is a 35 to 60 minute practice round on a built-in whiteboard. A voice AI interviewer asks follow-ups about what you drew, and you can ask for up to 3 hints.
Every mock ends with a Scorecard: a 0 to 100 score, 7 skill scores, your time on each step against a target, 3 fixes, your board next to a strong answer's board, and the key moments of the round.
The Scorecard is an AI estimate. The bar for your level (80 for Senior) is OphyAI's own benchmark, not any company's hiring bar.
Start a mock roundLive Copilot listens to the interviewer on your call and reads your whiteboard from a shared tab or window, or a phone photo. It keeps one design plan (requirements, estimates, API and data, a boxes-and-arrows diagram, deep dives) and for each question gives a short "Say this now" answer, what to draw next, the key number to mention, and how to handle pushback.
System Design is on the Premium plan ($59 a month, 500 credits): 30 credits a live session and 20 credits a practice round.
See how System Design worksThe classics come up again and again: design a URL shortener, a rate limiter, a news feed, a chat app, ride-hailing dispatch, a payment ledger, video upload and streaming, a web crawler, a notification system, search autocomplete, file storage and sync, ticket booking with seat holds, a real-time leaderboard, hotel reservations, food delivery tracking, a distributed cache, metrics and alerting, and an ad click aggregator. Each one tests a different core idea, such as caching, fan-out, idempotency or stream processing, so practicing all of them covers most of what you will be asked.
Use the same six steps every time: clarify the requirements, estimate the scale, write the API and data model, draw the high-level design, go deep on the two or three hardest parts, then wrap up with the trade-offs you made. Say your assumptions out loud, check in with the interviewer at each step, and tie every choice back to a requirement or a number.
Most system design rounds run 45 to 60 minutes. For 45 minutes, a good split is about 5 minutes on requirements, 4 on estimates, 6 on the API and data model, 12 on the high-level design, 14 on deep dives and 4 to wrap up. For 60 minutes, scale each step up: about 7, 5, 8, 16, 19 and 5 minutes. Offer your first deep dive by about two thirds of the way in.
Give yourself 2 to 4 weeks. Learn the building blocks first (caches, queues, sharding, replication, consistency, CDNs), then practice the classic questions out loud against a timer, two or three a week at first. Do a short estimation drill most days. In the last week, run full mock rounds on the whiteboard tool you expect to use, and redo the questions where you ran out of time.
They look for clear requirements before any drawing, numbers that drive decisions, a simple design that works end to end, depth on the hard parts, honest trade-offs, and clear communication. There is rarely one right answer. A reasonable design you can defend beats a fancy one you cannot explain.
Only rough math. You estimate requests per second, storage and bandwidth to the nearest power of ten or so, using round numbers such as 100,000 seconds in a day. The point is what the numbers mean for the design, such as needing a cache or sharding the database. See our back of the envelope calculation guide for the method and a free estimator.
Mid-level answers are expected to reach a working design with sensible components and some trade-offs. Senior answers drive the round, size the system with numbers, and go deep on bottlenecks, consistency and failure handling without being led. Staff answers also handle more ambiguity, weigh cost and operations, explain how the design evolves over time, and spot the risks that matter most.
Sometimes, but it is less common, and the bar is lower. Junior candidates more often get object-oriented design or a lighter design discussion. Full system design rounds are most common from mid-level up. It still helps to know the basics, such as caching, load balancing and databases.
The building blocks and when to use each one: load balancers, CDNs, caches, message queues, sharding, replication, consistency choices, SQL versus NoSQL, object storage, rate limiting, idempotency, search indexes and real-time connections. Add the numbers you will need for estimates, such as 86,400 seconds in a day and the common latency numbers. The cheat sheet on this page covers all of it.
Yes. OphyAI System Design has mock rounds for all 18 questions on this page: a 35 to 60 minute practice round on a built-in whiteboard with a voice AI interviewer who asks follow-ups about what you drew, and up to 3 hints. Every round ends with a Scorecard: a 0 to 100 score, 7 skill scores, your time on each step against a target, 3 fixes and your board next to a strong answer. The Scorecard is an AI estimate, and its bar is OphyAI's own benchmark. System Design is on the Premium plan ($59 a month), and a mock round uses 20 credits.
Pick any of the 18 questions, draw it on a whiteboard, and answer follow-ups from a voice AI interviewer. System Design is on the Premium plan.
