Use this template for EVERY system design interview question. It shows the interviewer you have a structured approach.

Ask clarifying questions:

• “What features are in scope?”
• “How many users? (DAU/MAU)”
• “Is this read-heavy or write-heavy?”
• “What are the latency requirements?”
• “Do we need real-time updates?”

Don’t assume. A URL shortener is very different from a video streaming service.

Quick back-of-the-envelope numbers:

Write 2-4 main endpoints:

POST /api/resource  →  { ... }
GET  /api/resource/:id  →  { ... }

Sketch the schema and choose storage type:

CREATE TABLE resource (id BIGINT PRIMARY KEY, ...);
-- or
// MongoDB document

Reasoning: “I’m using PostgreSQL because we need ACID… / MongoDB because the schema varies…“

Draw the block diagram:

flowchart LR
    Client["Client"] --> LB["Load Balancer"]
    LB --> App["App Servers"]
    App --> DB[("Database")]
    App --> Cache[("Cache")]

Explain the flow: “A request comes from the client, hits the load balancer, which routes to an app server. The app server checks the cache first. On cache miss, it queries the database.”

Pick 1-2 components and go deep. Common deep dives:

Be honest:

• “The database is a single point of failure right now — we could add read replicas.”
• “The cache improves reads by 10× but adds complexity for cache invalidation.”
• “We chose eventual consistency for the feed — users might see stale data for a few seconds.”
• “With more time, I’d design the sharding strategy more carefully.”

1. Requirements: shorten URL, redirect, basic analytics
2. Estimation: 100M URLs/day → ~1,200 QPS, 10TB storage over 5 years
3. API: POST /shorten, GET /{code}
4. Data: { id, short_code, original_url, created_at } in SQL
5. Design: Client → LB → App → Cache → DB
6. Deep dive: base62 encoding for short codes, cache-aside for redirects
7. Bottlenecks: DB write load → could shard by short_code prefix

• Use the 7-step framework for every question: requirements → estimation → API → data → HLD → deep dive → bottlenecks.
• The interviewer wants to see your thought process, not a perfect design.
• Admit trade-offs and discuss alternatives — that’s what senior engineers do.