What is Interview Forge?

Interview Forge helps you practice mock interviews, follow study plans, track career goals, review learning analytics, and prepare across 36 pages.

Design a URL Shortener (like bit.ly) for Full Stack Engineer

The problem for a Full Stack Engineer

Functional: shorten a long URL to a unique short code; redirect a short code back to the original URL; support optional custom aliases; return the same short code for a repeated long URL (dedup).
Non-functional: redirects must be fast (<50ms p99), highly available (redirects are the core product), and short codes should not be guessable if abuse matters.
Scale: ~100M new URLs/month, ~10B redirects/month — a 100:1 read-heavy workload.
Consistency: it is acceptable for a freshly created short code to take a few hundred ms to be globally readable; redirects must never return a wrong URL.

Out of scope (covered in detail below)

User accounts, custom dashboards, link editing, expiry, and abuse/spam detection — these are real product surfaces; we defer them and discuss how each would be built in the dedicated section.

As a Full Stack Engineer, the system design round will probe end-to-end feature ownership. Be prepared to go deep on the areas a Full Stack Engineer owns and to articulate trade-offs clearly.

Capacity estimation

Back-of-the-envelope numbers drive every choice. With 100M writes/month and a 100:1 read ratio, the system is dominated by reads, which points us straight at caching and CDN.

Resource	Estimate	Notes
Writes	~40/s	100M / month, ~30 days
Reads (redirects)	~4,000/s	100:1 read-heavy; peak ~3x
Storage (10 yr)	~500 GB	500B records x ~500 bytes (code + URL + meta)
Read bandwidth	~20 MB/s	4,000/s x ~5 KB response
Cache (hot set)	~50 GB	80/20 skew — 20% of codes drive 80% of reads

Architecture overview

High-level architecture

+--------+      +--------------+      +-------------------+
| Client |----->|  API Gateway  |---->|  Shortener Service |
+--------+      +--------------+      +-------------------+
                                             |     |
                        +--------------------+     +-------------------+
                        v                                              v
               +-----------------+                          +-----------------------+
               |  ID Service     |                         |  KV Store (code->URL) |
               |  (Snowflake)    |                          |  sharded by short code|
               +-----------------+                          +-----------------------+
                                                                   |
                                                                   v
                                                           +---------------+
                                                           |  Redis Cache  |
                                                           +---------------+
                                                                   |
                        +------------------------------------------+
                        v                                          v
               +----------------+                        +------------------+
               |  Analytics     |                        |  301 Redirect    |
               |  (Kafka)       |                        |  -> long URL      |
               +----------------+                        +------------------+

Reads flow through cache first; writes go through an ID service to guarantee uniqueness.

Step-by-step request flow

Write (shorten): client POSTs {long_url, alias?}. The service gets a unique ID from the ID service, base-62 encodes it, and persists (code -> long_url) in the KV store.
On a duplicate long_url, look up an existing mapping by a long_url hash key so the same URL returns the same code (saves storage, improves cache hit rate).
Read (redirect): client GETs /:code. Check Redis cache; on a hit, return 301 with the long URL. On a miss, read the KV store, populate the cache, then redirect.
Analytics: on every redirect, publish a click event to Kafka asynchronously — never block the redirect on analytics.
Cache miss protection: single-flight / per-code lock so a viral miss does not stampede the DB.

Unlock the full guide

Premium members get every DSA, system design, company and role interview guide — plus AI practice, mock interviews, and analytics.

Unlock with Premium