Loading…

Design a URL Shortener (Bit.ly) — SystemRound

Design a URL Shortener (Bit.ly)

easySystem design45 min5 stages

Asked atGoogleMicrosoftAmazonMetaUber

Design a URL shortening service like Bit.ly that takes long URLs and creates short, unique aliases. Users should be able to create short URLs, be redirected when visiting them, and optionally track click analytics. The system should handle millions of URLs and redirect requests with minimal latency.

Best as a first full rep: enough complexity to practice the interview shape without losing the thread.

What this problem tests

Core APIsAPI Design Quality301 vs 302 DiscussionCore ComponentsURL Shortening AlgorithmData Flow

Round shape

5 stages

Time budget

45 min

Feedback loop

Grade anytime

Guided practice·Primary loop

Guided practice

Workspace-first, hints visible, stage retry available. The cheap, repeatable loop — build the answer shape before you take it under pressure.

Stage-by-stage workspace instead of a blank page.
Grade one stage or the whole answer whenever you want.
Compare your answer against reference checkpoints and model answers.

Solve once, compare against the checklist, then come back to the weak stage instead of starting over.

Mock interview·Pressure test

Mock interview

Strict timer, hints hidden, debrief deferred to the end. Use this once you can already structure a clean answer and want to pressure-test pacing and pushback.

Best once the answer shape is already in your head.
Pressure-test pacing, pushback handling, and communication.
Use diagnosis after the interview for exact misses and next study steps.

Best after one structured rep · timed · focused on pacing and communication.

Requirements

This is the framing pass. A strong answer quickly defines what the system must do, what quality bar it has to hit, and the numbers that will justify the rest of the design.

First 5 min of the round

What must exist

Functional Requirements

5 items

1Given a long URL, generate a short and unique alias (short link)

2When users access a short link, redirect them to the original URL

3Users can optionally create custom short links

4Links expire after a configurable time (default: 5 years)

5Track analytics: click count, referrer, geographic location, device type

What good looks like

Non-Functional Requirements

5 items

1Very low latency for redirects — under 50ms p99

2High availability — 99.99% uptime, URL shortening is critical

3Short URLs should not be predictable or guessable

4System should be highly scalable — handle billions of redirects per month

5URLs once created should never be lost (high durability)

Numbers to anchor the design

Scale Estimation

6 items

1100M new URLs per month (write-heavy for creation)

2Read:Write ratio = 100:1 → 10B redirects/month

3QPS: ~3,800 writes/sec, ~380,000 reads/sec

4Storage per URL: ~500 bytes → 100M × 500B = 50GB/month → 3TB for 5 years

5Bandwidth: 380K × 500B = ~190MB/s for reads

6Cache: 20% of URLs drive 80% of traffic (Pareto) → cache hot URLs in memory

How the round unfolds

Each stage has a distinct job. Treat them like separate deliverables instead of one giant answer, and the round becomes much easier to navigate.

4 design stages · 40 pts after framing

🔌

Stage 2~5 min10 pts

API Design

Define the contract clearly: the endpoints, auth boundary, error semantics, and the one or two decisions that matter most.

What you should produce

Now let's define the API.

Strong answers cover

Core APIsAPI Design Quality301 vs 302 Discussion

🏗️

Stage 3~10 min10 pts

High-Level Architecture

Lay out the main components and trace the write path, read path, and any async path cleanly.

What you should walk through

Now walk me through the high-level architecture.

Strong answers cover

Core ComponentsURL Shortening AlgorithmData Flow

💾

Stage 4~10 min10 pts

Data Model & Storage

Pick the store, show the schema or key model, and explain why that storage choice fits the access pattern.

What you should lock in

Let's dive into the data model and storage.

Strong answers cover

Database ChoiceSchema DesignPartitioning & Replication

📈

Stage 5~15 min10 pts

Scaling & Deep Dive

Name the first bottleneck, failure modes, and the trade-offs that keep the system fast and reliable under pressure.

What you should pressure-test

Finally, let's talk about scaling this system.

Strong answers cover

Caching StrategyHigh AvailabilityDeep Dive Quality

What a strong first rep looks like

Scope clearly

Translate the prompt into concrete requirements, scale, and trade-offs before drawing architecture.

Stay stage-specific

Give APIs in the API stage, data models in the storage stage, and failure modes in scaling. Don't blur them together.

Iterate fast

Grade early, compare to the reference checkpoints, fix the biggest misses, and re-submit the weak stage instead of starting over.