Requirements

Functional Requirements

• Given a long URL, generate a unique short URL
• Given a short URL, redirect to the original URL
• Users can optionally set a custom short URL alias
• URLs expire after a configurable TTL
• Support analytics (click count, referrer, geographic data)

Non-Functional Requirements

• Latency: Redirect in < 10ms (99th percentile)
• Availability: 99.99% uptime (redirect is read-heavy)
• Durability: Short URLs must never be lost
• Scalability: 100M new URLs/month, 10:1 read-to-write ratio

Back-of-the-Envelope Estimation

API Design

POST /api/v1/urls
Request:  { "long_url": "https://...", "custom_alias": "my-link", "ttl_days": 30 }
Response: { "short_url": "https://sho.rt/abc123", "expires_at": "2026-07-20" }

GET /{short_code}
Response: 301/302 Redirect to original URL

DELETE /api/v1/urls/{short_code}
Response: { "status": "deleted" }

GET /api/v1/urls/{short_code}/analytics
Response: { "clicks": 1523, "unique_visitors": 892, "top_referrers": [...] }

High-Level Architecture

Detailed Design

ID Generation Strategies

The critical design decision is how to generate unique short identifiers:

Database Schema

CREATE TABLE urls (
    id          BIGINT PRIMARY KEY,
    short_code  VARCHAR(10) UNIQUE NOT NULL,
    long_url    TEXT NOT NULL,
    user_id     BIGINT,
    created_at  TIMESTAMP DEFAULT NOW(),
    expires_at  TIMESTAMP,
    click_count BIGINT DEFAULT 0
);

CREATE INDEX idx_short_code ON urls(short_code);
CREATE INDEX idx_expires_at ON urls(expires_at);

Caching Strategy

Given the read-heavy workload, caching is essential:

• Cache-aside pattern: Check cache first, fall back to DB, populate cache on miss
• LRU eviction: Evict least recently accessed URLs
• TTL matching: Cache entries expire when URLs expire
• Cache hit ratio target: > 99% for hot URLs

Collision Handling

When generating short codes, collisions must be handled gracefully:

1. Retry with different salt: Append timestamp or random bits and re-hash
2. Check before insert: Verify uniqueness before writing to database
3. Use longer codes: Increase length if collision rate is too high
4. Database constraint: Let the unique constraint catch collisions and retry

Scaling Considerations

Read Path Optimization

The redirect path must be extremely fast:

1. Client requests short URL
2. Load balancer routes to nearest app server
3. App server checks Redis cache
4. Cache hit → return long URL immediately (sub-millisecond)
5. Cache miss → query database, populate cache, return

Write Path Optimization

Creating new URLs is less latency-sensitive:

1. Client submits long URL
2. App server requests ID from ID Generator service
3. App server encodes ID to Base62 short code
4. Write to database (can be async)
5. Populate cache proactively
6. Return short URL to client

Database Sharding

Partition the URL table by short_code hash:

Practice Exercises

1. Design: How would you implement custom aliases (user-chosen short codes)? What additional constraints and validation are needed?

2. Scale: If the system handles 1B short URLs and 100K QPS reads, estimate the Redis cache memory needed assuming 500 bytes per entry and 99% cache hit ratio.

3. Trade-offs: Compare using a Snowflake ID vs a pre-generated ID pool for the URL shortener. What are the latency and complexity trade-offs?

4. Edge Case: How would you handle a viral URL that suddenly receives 10M requests in one minute? Design a strategy to prevent cache stampede.

What to Learn Next