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.

here the main component are

1. ID Generation Service (Core of System)

🔹 Why it matters

Must guarantee global uniqueness
No collisions → otherwise wrong redirects
High throughput (millions/sec)

🔹 Approach → Snowflake-style ID

Structure:

[ timestamp | machine_id | sequence ]

timestamp → ordering
machine_id → uniqueness across nodes
sequence → multiple IDs per ms

Then:

ID → Base62 encode → short_code

🔹 How it works

Request → ID service
Generate ID using local state
Encode → return short_code

🔹 Scaling

Stateless → horizontal scaling
Each node has unique machine_id
No DB dependency → avoids bottleneck

🔹 Tradeoffs

OptionProsCons
DB auto-inc	Simple	Bottleneck
UUID	No coordination	Long, not URL-friendly
Snowflake	Fast + scalable	Clock sync dependency

🔥 Key Point

This service must never generate duplicate IDs — it’s the backbone of the system.

2. Database Design (Partitioning + Indexing)

🔹 Problem

Billions of rows
Fast lookup by short_code
Heavy read traffic

🔹 Schema (SQL)


short_code (PK)
long_url
created_at
expiry

🔹 Indexing

Primary index on:

short_code

→ ensures fast lookup

🔹 Partitioning / Sharding

Best Approach → Hash-based

shard = hash(short_code) % N

✔ evenly distributes load

✔ avoids hotspot

🔹 Scaling Strategy

Start:
- Single DB
Scale:
- Read replicas (for redirect)
- Sharding (for large scale)

🔹 Tradeoffs

StrategyProsCons
Single DB	Simple	Not scalable
Sharding	Scalable	Complex routing
Read replicas	Better reads	Replication lag

🔥 Important Correction (from your point)

“We can’t scale more because routing is complex”

👉 Correct version:

We can scale horizontally
But:
- Need consistent hashing / routing layer
- Handle replication lag + consistency

3. Caching Layer (Redis)

🔹 Purpose

Reduce DB load
Achieve low latency (<10ms)

🔹 Strategy → Cache-Aside

Read Flow

Redis → DB fallback → update Redis

Write Flow

DB write → Redis update (write-through)

🔹 Data Model

key: short_code
value: long_url

🔹 Scaling

Redis Cluster
Partition keys across nodes

🔹 Problems & Solutions

❗ Hot Key (viral URL)

One key → huge traffic
✔ Use:
CDN caching
Replication

❗ Cache Miss Storm

✔ Use:

Request coalescing
Locking

❗ Eviction

LRU / TTL

4. Rate Limiter (Protection Layer)

🔹 Purpose

Prevent:
- DDoS
- abuse
- DB overload

🔹 Approach

Token bucket / sliding window
Implement at:

CDN / Edge (best)

🔹 Tradeoffs

Strict limits → may block real users
Loose limits → risk overload

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10