Detailed Component Design

1. ID Generation

Approach: Generate a unique 7-character short code using base62 encoding (a-z, A-Z, 0-9).

To avoid collisions at scale, use a distributed ID generator:

Reserved bits for a timestamp (atomic-clock-based) to ensure time-ordered uniqueness
Remaining bits for a machine/node ID and a sequence counter
This produces globally unique IDs without a central coordinator — no single point of failure
Collisions are effectively impossible, so no retry logic needed

Security: Codes are random-looking, making it hard for attackers to enumerate valid short URLs at scale.

2. Caching

Architecture: A Redis cluster sits between the redirect service and the database.

Read path:

Client requests GET /abc123
Service checks Redis first — cache hit (~99%) → immediate 301 redirect
Cache miss → query DB, populate Redis with a TTL (e.g., 24 hours), serve redirect

Hotspot mitigation: Viral links all hit one DB shard, but the cache absorbs the load — the first request hits the DB, then all subsequent clicks hit Redis (sub-millisecond). The DB shard sees minimal traffic regardless of popularity.

TTL & Eviction: Entries expire after 24 hours to prevent memory bloat. LRU eviction frees space for popular entries.

3. Partitioning (Sharding)

Strategy: Hash the short code (e.g., hash(short_code) % N) to route each redirect to exactly one shard. No scatter-gather needed.

Data redistribution: When adding a new shard, use consistent hashing to minimize data movement — only a fraction of entries need rebalancing.

Hotspot mitigation (already covered by cache above).

4. Rate Limiting

Per-IP throttling: Limit to 100 writes/minute per IP to prevent abuse. Burst handling: Token bucket algorithm allows short bursts while enforcing a steady average. Return HTTP 429 with Retry-After header.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10