SysPad › Interview practice

Interview practice

Common interview questions about system design. Each one is a diagram you can open and simulate.

Start with a worked problem. Then try the other problems on your own.

Worked problems

One question, worked one twist at a time. A simulation checks each change to the design.

• Design a URL shortener: URL shortener system design, worked step by step. Size it from 5 million links a day, lease ID blocks, cache a viral link and batch the click counts.
• Design a rate limiter: Rate limiter system design: compare six counting algorithms, size the counter store for the storm it must stop, and survive a leaked API key.
• Design a notification system: Notification system design, worked: know each provider's ceiling, decide which messages wait when you hit it, and keep sign-in codes flowing on a bad day.
• Design a hotel reservation system: Design a hotel reservation system that never sells a room twice. Then find what breaks first when metasearch floods searches or a convention block opens.
• Design a payment system: Payment system design, worked: charge each card once, keep books that balance, and find what breaks on Black Friday or when the primary processor fails.
• Design a digital wallet: Digital wallet system design: retries that move money once, no overdraft under concurrent debits, and one wallet taking 600 donations a second.
• Design a web crawler: Web crawler system design. Size the crawl in pages a second and dollars per million pages, dedupe with a Bloom filter, and stay polite to every host.
• Design a metrics monitoring and alerting system: Metrics and alerting system design: size it by series, stop one team's high-cardinality label from sinking the rest, and keep alerts firing.
• Design an ad click aggregation system: Ad click aggregation system design: count every click exactly once, survive a viral ad and a sports final, and fix two days of wrong totals.
• Design an email service: Email service system design: accept mail only once it is safe, erase one user from packed files, and contain a hijacked account that starts spamming.
• Design a proximity service: Proximity service system design. Find nearby places in a few cache reads, size the caches by network and key rate, and survive a node lost at the lunch peak.
• Design search autocomplete: Search autocomplete system design: precompute the suggestions, let the client set the request rate, and see what a new mobile app does to the shards.
• Design Google Drive: Google Drive system design: sync only changed blocks, notify devices instead of polling, keep file bytes off your servers, and absorb photo and video sync.
• Design YouTube: YouTube system design: encode chunks in parallel, spend AV1 encodes only on videos that earn views, and keep view counts off the database.
• Design Google Maps: Google Maps system design: a road graph re-weighted by live traffic every minute, location batched on the phone, and map tiles as the real bill.
• Design a chat system: Chat system design: an inbox per user for small chats, channels stored once and delivered by subscription, and a reconnect that reads only what changed.
• Design a nearby friends feature: Nearby friends system design: push location instead of polling, size the gateways for connects rather than updates, and deploy without a reconnect storm.
• Design a gaming leaderboard: Gaming leaderboard system design: keep scores in the database, serve ranks from a sorted set, and replay a run before it enters the top 1,000.
• Design a key-value store: Key-value store system design: size the ring by what its copies hold, survive a dead node, and fix a flash-sale hot key in its callers.
• Design a unique ID generator: Unique ID generator system design at 10,000 IDs a second. Find what every ID waits on, take it off the path, and know what each of the 64 bits buys.
• Design a news feed: News feed system design. Compare pull, push and hybrid timelines, then handle a celebrity with a million followers and a live-event spike.
• Design a distributed message queue: Distributed message queue system design. Size the log by what it holds and how many consumer groups read it, keep a week of history, and fix a hot key.
• Design S3-like object storage: S3-like object storage system design: cut replication overhead with erasure coding, split hot data from cold, and make the metadata row the commit point.

Problems to try

Each one is a complete architecture. Open it, run the simulation, then change the design and run it again.

• Rate limiter: Sliding-window rate limiting at the edge. A limiter fleet checks and increments a sharded Redis counter before requests reach the backend, with live-updatable rules and an async metrics pipeline. Why the counter store, not the backend, is the bottleneck: allowed and throttled traffic both hit it, so it saturates first under combined load.
• Distributed key-value store: A coordinator implements quorum reads/writes (W+R>N) against Keyspaces - the consistent-hashing ring, gossip membership, and vector clocks are internal to the managed Cassandra-compatible store. A scheduled anti-entropy worker reconciles divergent replicas. The ring abstracted into one managed component, a coordinator layer for quorum logic, a hot-key cache, and Merkle-tree anti-entropy as a background job.
• Unique ID generator: A stateless Snowflake-style ID generator - no per-request coordination, just a one-time machine-ID lease at cold start, with clock-drift monitoring so timestamps never move backwards. A purely computational service: near-zero latency, no database on the hot path, and the one piece of shared state (the machine-ID lease) kept off it.
• URL shortener: Cache-aside redirect reads (app servers → Redis → DB on miss), a dedicated base62 ID-generator on the write path, and an async click stream feeding an analytics lake. The read/write split - a heavily-skewed redirect read path kept off the database by cache, ID minting as its own service, and click analytics decoupled onto a stream.
• Web crawler: URL Frontier → HTML Downloader (+ DNS Resolver) → Content Storage + Parser → content dedup (checksum) and URL dedup (Bloom-filter role via Redis). A scheduler re-enqueues known pages for freshness. A crawl pipeline with dedup stages explicit, and the discovery/recrawl feedback loop modelled honestly as a scheduled re-feed rather than a cycle the simulator can’t traverse.
• Notification system: A Notification Server fans out to one queue per channel (push/SMS/email) so a slow channel can’t back up the others - SNS for push, Twilio for SMS, SES for email - after checking each user’s opt-in settings. Per-channel queue isolation with the preference/opt-in check that decides which channels a given notification actually fans out to.
• News feed system: A Fanout Service pushes new posts into followers’ feed caches on write (reading the social graph); a Feed Service assembles reads from the pre-computed cache + hydrated post content + CDN media. Fan-out-on-write publishing alongside cache-assembled feed reads sharing one app tier - reads stay cheap because the expensive work happens once, at write time.
• Chat system: An NLB (not ALB - connections are long-lived and stateful) fronts WebSocket chat servers, with a Redis presence tracker, a Cassandra-style message store, and push notifications for offline users. Why chat needs an L4 load balancer, and message persistence kept separate from presence tracking so a message send both durably stores and routes in one hop.
• Search autocomplete: API servers read from an in-memory Trie Cache (falling through to a Trie DB); every query is logged and periodically re-aggregated into a rebuilt trie by an offline, scheduled Trie Builder. A very high-QPS read path decoupled from a slow, periodic trie-rebuild pipeline fed by the same query stream - the reads never wait on the rebuild.
• Design YouTube (upload + playback): Upload → original storage → a transcoding-queue-driven worker pool (multi-stage DAG: codecs, resolutions, thumbnails) → transcoded storage + a completion handler updating metadata, with playback served from CDN. The upload and transcoding pipeline, plus the CDN-served playback read path - two very different traffic shapes on one system.
• Design Google Drive: A Block Server chunks/compresses/encrypts files into Block Storage, a Metadata DB tracks file/block/version relationships separately, a Notification Service syncs other clients on change, and a scheduled job tiers cold blocks to archival storage. Splitting block storage from metadata, change notification as its own async path, and cold-tiering as a scheduled background job.
• Proximity service: A read-heavy Location-Based Service fans each search into 9 geohash-cell reads on a sharded Redis cache, a small Business Service handles CRUD and detail pages through an info cache, and a nightly batch rebuild is what makes owner edits visible next day. Read/write asymmetry as an architecture: the search path is cache-first and 9x-amplified, writes skip the caches entirely, and freshness is a scheduled batch job, not cache invalidation.
• Nearby friends: Periodic pings over WebSocket fan out via per-user Redis Pub/Sub channels to ~40 online friends each, so delivery runs 40x the ping rate back onto the same socket tier (a Return edge closes the loop); the latest location lives only in a TTL cache and history is written off the hot path. Fan-out amplification as the real load: 6k pings/s become 240k deliveries/s landing back on the ONE socket fleet that sent them - a drawn loop the Return edge keeps out of the topology math while the delivery flow carries its load.
• Google Maps: Navigation loads precomputed routing tiles from object storage and prices every route against a Live Traffic store; that store is fed by a firehose of user location pings streaming through Kafka; map images serve straight from a CDN; and the tiles themselves are rebuilt offline, never edited live. One shared traffic store as the meeting point of two opposite workloads - a high-volume ping stream writing it and every routing query reading it - plus precomputation as an architecture: the online paths only read tiles that an offline batch produces.
• Distributed message queue: Producers write to a partitioned, replicated broker cluster (MSK). Two consumer groups each drain the full log independently, one into durable storage and one into real-time analytics. The headline message-queue property: one durable log written once and read in full by every independent consumer group, so the broker’s read load is a multiple of its write load.
• Metrics monitoring & alerting: Agents push metrics through a collection stream into a time-series DB; a Query Service feeds dashboards while an Alert Manager evaluates rules against the same store and pages out. One TSDB serving both a dashboard read path and an independent alert-evaluation path.
• Ad click event aggregation: Click events are deduplicated once, then split into a real-time stream aggregator (fast, approximate) and a raw-event archive feeding a periodic batch reconciliation job (slow, accurate). The real-time-vs-batch accuracy trade-off, sharing one dedup gate.
• Hotel reservation system: A cache-backed Search Service (staleness-tolerant) is split from a Reservation Service that writes straight to the primary DB (strong consistency, to avoid overbooking), then queues an async confirmation email. Deliberately different consistency requirements on two paths sharing the same inventory database.
• Distributed email service: Mail API → Mail Processor → spam/virus filter → delivery queue → a handler that fans out to attachment storage, metadata, search indexing, and SES for SMTP delivery. Spam filtering as a mandatory gate before anything reaches the delivery queue.
• S3-like object storage: An Object API separates Metadata Store lookups from a Placement Service that routes bytes to replicated data nodes (S3 itself stands in for that layer), plus a background compaction job. Metadata/placement/data-node separation - the same three-layer split S3 itself uses internally.
• Real-time gaming leaderboard: Score submissions go straight into a Redis sorted set (ZADD/ZRANGE/ZRANK) for O(log n) ranking; the database only sees a fraction, for durability. A sorted set doing the actual ranking work, with the database relegated to an async durability path.
• Payment system: A Payment Service checks an idempotency-key store before calling the PSP (Stripe) - so a retried request can’t double-charge - then writes the ledger and emits an event for reconciliation and fraud detection. Idempotency-key checking as a mandatory gate before any external payment call, and one event feeding two independent downstream consumers.
• Digital wallet: Balance-changing operations write straight to an ACID double-entry ledger DB, which then updates a balance cache and appends to transaction history - reads are cache-fast, writes are deliberately not. A relational, transactional ledger as the source of truth, with a cache serving only the read-heavy balance-check path.

Open the SysPad canvas · Architecture examples · Lessons · How-to guide