System Design Prep

For mid and senior rounds. Practice real designs and get scored across the dimensions interviewers actually evaluate — not just the diagram, but the reasoning behind it.

Request a topic

Not covered yet? Describe it and we'll generate a worked guide, file it in the right section, and save it here for reuse.

Open the System Design Library

Each scenario opens a full staged walkthrough: requirements, capacity estimation, a rough sketch, and a final architecture.

Filter the Prep Library

Browse all

Coding Algorithms & Data Structures System Design AI / ML Context Engineering CAD & Mechanical Design Mock Interview Assessments Non-technical

Practice scenarios — tap to open the library

URL shortener Chat system News feed Rate limiter File storage Search autocomplete Notification system Ride-sharing system Payment system Job matching system Resume parsing system Recommendation engine

Evaluation rubric

Requirements clarificationAPI designData modelScalabilityCachingQueuesDatabasesTradeoffsBottlenecksReliabilitySecurityCost awareness

Interactive walkthrough

Pick a scenario for its architecture diagram, the step-by-step solution, and realistic interview Q&A.

URL shortener — architecture

Mid

ClientEdgeServiceDataAsync

Solution, step by step

1
Functional requirements
- Shorten a long URL to a short key
- Redirect a short key to the original URL
- Optional: custom aliases, expiry, click analytics
2
Non-functional requirements
- Read-heavy (~100:1 read:write)
- Redirect latency < 50ms p99
- 99.99% availability for redirects
- Links are effectively permanent (high durability)
3
Capacity & estimation
- ~100M new URLs/month → ~40 writes/s avg, ~400/s peak
- Reads ≈ 100× writes → ~40K reads/s peak
- 5 years ≈ 6B URLs; ~500 bytes each → ~3 TB
- Short key: base62, 7 chars → 62^7 ≈ 3.5T keys (ample)
4
Preliminary design
- Generate a unique ID, base62-encode it to a 7-char key
- Store key → long URL in a KV store
- On read, look up and 301/302 redirect
5
Final architecture
- Stateless API behind a load balancer; separate read and write paths
- Distributed ID generator (snowflake / counter ranges) to avoid collisions
- KV store (DynamoDB/Redis) partitioned by key; replicas for read scale
- CDN + edge cache for hot keys; 301 for cacheable, 302 when tracking clicks
- Async analytics pipeline (Kafka → warehouse) so redirects stay fast

Interview Q&A (9)

Take a globally unique ID from a distributed generator (Snowflake or pre-allocated counter ranges) and base62-encode it. That avoids coordination on the hot path and guarantees no collisions.