System Design Questions

Design a URL shortener like bit.ly — map a long URL to a short unique alias and redirect back at scale. The core problems are generating collision-free short keys and serving billions of low-latency redirects.

Pastebin lets users store and share plain text through unique URLs. Developers use it for code snippets and configuration files. The core challenge: generate unique short URLs and serve content with low latency at scale.

Design a webhook service that processes incoming requests and ensures efficient, secure handling of real-time events, such as payment notifications from services like Stripe or Shopify.

Design the suggestion service behind a search box — as a user types, return the few most-relevant completions of their prefix faster than the next keystroke. The hard part is ranking a huge corpus inside a per-keystroke time budget.

Design the core of a location-based dating app — a candidate feed to swipe through and a mutual-match detector. The swipe write firehose, not the candidate feed, is the load that shapes the design.

LeetCode system design for an online judge that runs untrusted code safely, grades submissions under strict limits, and serves a live contest leaderboard at scale.

Distributed rate limiter system design for API requests, including atomic counters, token buckets, sliding windows, multi-region coordination, and failure behavior.

Design a calendar where events repeat, span timezones, and involve many attendees. The hard part is that a recurring event is a rule, not a list — you store the generator and expand it per query window.

Design a simplified version of Twitter where users can post tweets, follow/unfollow other users and is able to see the tweets of its followings.

Design a local business discovery platform with geo-based search and crowd-sourced reviews.

Design a streaming service that plays a curated catalog smoothly to tens of millions of concurrent viewers. The hard part is delivery economics — hundreds of terabits per second that must come from the edge, not the origin.

Users watch live prices tick and tap "buy" — two systems with opposite requirements have to work together, a lossy price broadcast and an exactly-once ledger that must never lose track of anyone's money.

Design a file-sync service like Dropbox — a folder of files lives on many devices, and an edit on one device appears on every other device within seconds. This is a sync problem before it is a storage problem.

Design a collaborative document editor — many people type into the same document at once, every keystroke shows up for others within a moment, and everyone converges to the identical text with no edit ever silently lost.

Design a ticket-booking system with assigned seats — browse availability, hold a seat, and buy it, and the same seat must never sell twice. A popular on-sale is a synchronized stampede, and inventory correctness under that contention is the hard part.

Millions of viewers watch one broadcast and expect every new comment to stream in instantly. At peak, comments arrive faster than any person can read — fan-out alone isn't the hard part.

Crawl tens of thousands of news sources and show a fresh, ranked feed. The trap is a time-sorted list of raw articles — the real problem is recognizing that twenty articles are one story.

A user types a multi-word query and expects the best-matching posts out of billions, ranked, in milliseconds. Scanning post text at query time is impossible — the design turns on inverting the corpus.

Design local, on-demand delivery of physical goods — a shopper sees what a nearby store actually has in stock, orders it, and watches a courier bring it. Live inventory, not courier dispatch alone, is what makes this hard.

Design a real-time auction — many bidders compete on an item, the price climbs live in front of thousands of watchers, and the auction closes at a deadline with an unambiguous winner. One item is both a write hotspot and a read hotspot at once.

Millions of hosts emit numeric measurements every few seconds. The trap is modeling it as one database you insert rows into — the real fight is against cardinality, not raw volume.

Distributed job scheduler system design for one-off and recurring jobs, with time buckets, leases, retries, crash recovery, and effectively-once execution at scale.

Design a system that moves money between a payer and a payee, correctly, even when every step runs over networks that fail and the external payment provider can't participate in your database transaction.

Design a system that crawls the web at scale — starting from seed URLs, fetching pages, and following links, billions of pages deep. Dedup and per-host politeness, not raw fetch throughput, are what break a naive queue.

Design a pipeline that counts ad clicks accurately for billing while giving advertisers near-real-time aggregates. Duplicate deliveries and hot-key skew, not raw click volume, are what break a naive counter.

Design a system that surfaces the top K trending items — videos, songs, search queries — from a firehose of events. Unbounded distinct items against bounded memory, not raw event volume, is what breaks a naive counter.

Design the core of a ride-hailing service — drivers stream location, riders find and match a nearby driver. The twist is that it is write-heavy; the location index takes a firehose of updates, far more than the rider-request reads.

Design a durable, high-throughput message system that decouples producers from consumers — producers append events; many independent consumer groups read at their own pace, replay history, and survive each other's failures. The Kafka lineage — a partitioned, append-only log, not a transient queue.

Chat app system design for WhatsApp or Messenger, covering WebSocket gateways, ordered delivery, offline sync, group chat, presence, and durable storage.

Design a video platform where users upload videos and a global audience streams them. The hard parts are the transcode pipeline and delivery economics — serving video is an egress-bound problem measured in exabytes.

Design the home feed for a social product — a ranked, near-real-time stream of posts from followed accounts. The hard parts are fan-out and ranking, and they are coupled.

Design a photo-sharing service — upload images, follow accounts, and see a timeline of recent posts. The read path is a News Feed variant; the new problem is the media write path — upload, transcode, durable blob storage, and CDN delivery.

Design an in-memory caching layer that serves reads at sub-millisecond latency for tens of millions of requests per second, shards across many nodes, survives node loss without taking the database down, and has a defensible answer for stale data.

Design a horizontally-scalable key-value store that stays available and low-latency across hundreds of nodes and multiple datacenters, survives node and network failures, and has a defensible answer for what a read returns after a write that raced a partition. The Dynamo / Cassandra / Riak lineage.

Design a mapping service like Google Maps

Design the retrieval layer behind "chat with your data" — ground answers in a private, per-tenant corpus of billions of chunks that changes every minute. The hard parts are approximate vector search that fits in memory, retrieval quality, and filtering by tenant without breaking the index.

Design a conversational assistant whose replies stream from a large language model. The reply is a GPU computation produced one token at a time, so the design is an inference-serving and scheduling problem wrapped in a chat product.

Design a text-to-image service. Each image is a fixed block of GPU work that takes seconds, produces a large binary, and must pass a safety check on both ends before anyone sees it.

Design a terminal coding agent like Claude Code. The model runs remotely, the code and the shell live on the user's machine, and the repository is far larger than the model's context window. The hard part is the harness — a bounded tool-use loop, a local permission gate, and a token budget.

Design a deep-research feature for an AI assistant. One hard question becomes a minutes-long job that searches the web, reads dozens of sources, and returns a cited report. The hard part is staying grounded inside a fixed budget of tokens, time, and searches.

Design the serving layer that lets one LLM assistant answer at low, medium, high, or max reasoning effort. The hard part is that effort multiplies cost per request, so cheap requests must stay fast while expensive ones run.