Designing A Simple Url Shortening Service A TinyURL Approach - System Design

Requirements

Functional Requirements:

Create a short URL for a given long URL.
Return the long URL associated with a given short URL.

Non-Functional Requirements:

High availability (99.99%) — redirects must always work
Low redirect latency (< 50ms) — fast redirects are the core experience
Scalable — handle millions of URLs and requests
List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

API Design

create -

POST /api/url/shorten Request: { "long_url": "https://verylongurl.com/..." } Response: { "short_url": "tinyurl.com/abc123", "expires_at": "..." } Optional: { "custom_alias": "my-link", "ttl_days": 30 }.

redirect -

GET /{short_key} → 301 Moved Permanently Location: https://verylongurl.com/...

delete

DELETE /api/url/{short_key} Request Header: Authorization: Bearer <token> Response: 204 No Content

get url info

GET /api/url/{short_key}/info Response: { "long_url": "...", "created_at": "...", "clicks": 12345 }

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

-- Core Table: URL MappingsCREATE TABLE url_mappings ( id BIGINT PRIMARY KEY, -- sequential ID from ID generator short_key VARCHAR(10) UNIQUE NOT NULL, -- "abc123" (base62) long_url TEXT NOT NULL, -- original long URL user_id BIGINT, -- optional: who created it created_at TIMESTAMP NOT NULL DEFAULT NOW(), expires_at TIMESTAMP, -- NULL = never expires click_count BIGINT DEFAULT 0 -- denormalized for speed);-- Indexes for fast lookupsCREATE INDEX idx_short_key ON url_mappings(short_key);CREATE INDEX idx_user_id ON url_mappings(user_id);CREATE INDEX idx_created_at ON url_mappings(created_at);

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

🔧 1. ID Generation (Short Key)

Algorithm: Base62 Encoding

Use a distributed counter (e.g., Snowflake-style or Redis INCR) to get a unique sequential ID
Encode the ID in Base62 (0-9 + a-z + A-Z) = 62 characters
7 characters → 62⁷ ≈ 3.5 trillion unique URLs — plenty of room

Collision handling:

DB has UNIQUE INDEX on short_key
If collision occurs (extremely rare), retry with next ID
This is deterministic — no collision risk unlike random generation

Hard to guess? Base62 encoded sequential IDs are predictable. For better security: hash the sequential ID (e.g., take last 7 chars of MD5(ID + secret_salt)).

High availability: Each app server can pre-fetch a batch of IDs (e.g., 10,000) from the ID generator — if the generator goes down, servers still have a local buffer.

🧠 2. Caching Layer (Redis)

Aspect	Design
Cache type	Redis (in-memory, sub-ms reads)
Key	`short_key`
Value	`long_url`
TTL	24 hours (LRU eviction if full)
Write-through	On URL create, immediately cache it

Cache miss path:

Client → Redirect Service → Cache Miss → Query DB → Return redirect → Write to Cache

Viral link protection:

Hot URLs stay in cache → DB never sees spike
If Redis fills up, LRU eviction removes cold entries

Cache invalidation:

On URL disable/delete → DEL short_key in Redis + purge CDN

🗂️ 3. Database Partitioning

Shard by short_key hash:

shard_id = hash(short_key) % N

Benefit	Why
No scatter	One shard hit per redirect — no cross-shard queries
Even spread	Hash distributes uniformly
Hotspot mitigation	Redis cache absorbs hot keys before they hit shar