Designing A Url Shortener (Bit.ly / TinyURL)

1) Problem Clarification / Làm rõ bài toán

EN

We need to design a system like Bit.ly that generates short URLs and redirects users to the original long URLs.

We ask clarifying questions:

How many users?
What is traffic volume?
What level of availability is required?
Should URLs expire?
Do we support analytics (click counts, location, referrer)?

VI

Thiết kế một hệ thống giống Bit.ly tạo short URL và chuyển hướng về URL gốc.

Các câu hỏi cần hỏi:

Có bao nhiêu người dùng?
Tải hệ thống thế nào?
Yêu cầu availability ra sao?
URL có hết hạn không?
Có theo dõi analytics (số click, location, referrer) không?

2) Non-Functional Requirements / Yêu cầu phi chức năng

EN

High availability: 99.9%+
Low latency (<10 ms lookup)
Scalability to billions of links
Collisions must be avoided
Consistent redirect

VI

Độ sẵn sàng cao: 99.9%+
Trễ thấp (<10 ms khi resolve)
Scale đến hàng tỷ link
Tránh trùng key
Redirect phải chính xác

3) Estimating Scale / Ước lượng tải

EN

Assumptions:

100M users
1B total links
50M new URLs/month
200 reads per write

VI

Giả định:

100M người dùng
1 tỷ short links
50M link mới mỗi tháng
Tỷ lệ đọc/ghi: 200 lần truy cập cho 1 lần tạo link

4) High-Level Architecture / Kiến trúc tổng quan

Client → API Gateway → URL Service → Cache → Database  
                                   → Analytics Pipeline

EN

API handles creation + redirection
Cache speeds up lookups
DB stores mappings
Analytics processed asynchronously

VI

API xử lý tạo + redirect link
Cache tăng tốc truy vấn
DB lưu mapping
Analytics xử lý async

5) URL Key Generation / Sinh mã Short URL

EN

Options:

Sequential ID + encoding (base62)
Hash-based (MD5/SHA1) with collision handling
Twitter Snowflake distributed ID generator

Pick Base62 encoded ID — predictable length and collision-free.

VI

Lựa chọn:

ID tuần tự + encode base62
Hash-based + xử lý trùng
Snowflake

➡️ Chọn base62 mã hóa ID: độ dài cố định, tránh trùng.

6) Data Model / Thiết kế DB

EN

Relational (PostgreSQL, MySQL) schema:

URL_TABLE (
   id BIGINT PRIMARY KEY,  // encoded as short URL
   long_url VARCHAR,
   created_at DATETIME,
   expiration DATETIME NULL,
   user_id BIGINT
)

Index on: long_url and created_at.

VI

Schema quan hệ:

URL_TABLE (
   id BIGINT PRIMARY KEY,
   long_url VARCHAR,
   created_at DATETIME,
   expiration DATETIME NULL,
   user_id BIGINT
)

Index: long_url, created_at

7) Caching Strategy / Chiến lược Cache

EN

Redirect lookup must be sub-10ms → Redis in front of DB.

Approach:

Cache-aside pattern
TTL ~ 24 hours
LRU eviction
Hot-key sharding if celebrity links explode

VI

Redirect phải sub-10ms → Redis.

Cách:

Cache-aside
TTL ~24h
LRU eviction
Shard key nếu hot-link quá tải

8) Analytics Processing / Thu thập thống kê

EN

We do not want analytics to block redirect.
Instead:

Redirect API → Kafka → Consumer → Aggregation DB

VI

Không xử lý thống kê đồng bộ.

Flow:
Redirect API → Kafka → Consumer → DB thống kê

9) Scalability Discussion / Khả năng mở rộng

EN

When DB grows:

Range sharding on ID prefix
Cache helps scale reads
Write operations are append-only

For Snowflake or MySQL auto-increment, ensure ID continuity across shards.

VI

Khi DB tăng:

Shard theo prefix ID
Cache giảm tải read
Ghi là append-only

Snowflake/Auto-increment cần đảm bảo ID không đụng nhau trên shard.

10) Handling Failures / Xử lý lỗi

EN

Redis down? → fallback to DB
DB slow? → return 302 async after retry
Collision? → random retry + monitoring

Rate limiting protects spam abuse.

VI

Redis chết? → Query DB.
DB chậm? → Retry, degrade mode.
Trùng key? → retry.

Cần rate limiting chống spam.

11) Observability / Giám sát vận hành

EN

Key metrics:

cache hit rate
redirect latency
error rate
message queue lag
dangling link %

VI

Metric cần quan sát:

cache hit rate
latency redirect
error rate
queue lag
số link hỏng