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:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
• Availability
• Latency in millisecond
• Scalability

Capacity Estimation

aily active users 10 million Popular service

New URLs created per day 100 million ~10 URLs per user

Read/Write ratio 100:1 For every 1 URL created, 100 people click it

Step 2: Calculate QPS (Queries Per Second)

Writes (URL creation):

100M URLs per day ÷ 86,400 seconds ≈ 1,200 writes/sec

Reads (Redirects):

1,200 × 100 (read ratio) = 120,000 reads/sec

Peak traffic: Multiply by 2-3x ⇒ ~3,600 writes/sec and ~360,000 reads/sec

Step 3: Storage

Each URL entry needs roughly:

Short key (6 chars) + Long URL (500 chars avg) + Created date + User ID ≈ ~1 KB

Time Total URLs Storage

1 day 100M 100 GB

1 year 36.5B ~36 TB

Pro tip: Mention you'd use TTL/expiration (auto-delete old URLs after 1 year) to cap storage.

Step 4: Bandwidth (Optional but nice)

Writes: 1,200 writes/sec × 1 KB = ~1.2 MB/s incoming Reads: 120,000 reads/sec × 1 KB = ~120 MB/s outgoing

Here's a quick template you can paste in:

Assumptions:

100M new URLs/day, 100:1 read:write ratio

QPS:

Writes: ~1,200/sec (peaks at ~3,600)

Reads: ~120,000/sec (peaks at ~360,000)

Storage:

~100 GB/day, ~36 TB/year (before cleanup)

Bandwidth:

In: ~1.2 MB/s, Out: ~120 MB/s

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

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.

core components --> Write DB

Read operation separate DB - Read Replication

Load Balancer - to multiple request will go to different through LB to service

Redis Cache is optional I will use it for strong consistency otherwise I will skip as tiny url will be eventual consistency is enough

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...

Table: urls

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.

 race condition scenario

1. User A creates URL → generates random key "abc123"
2. User B creates URL → generates random key "abc123" (same!) at the same time
3. Both check DB → both see "abc123" doesn't exist
4. Both insert → one succeeds, one fails on unique constraint

How to handle it

Step 1: Unique constraint on short_key

• This is your safety net — the DB won't allow duplicates
• The second insert throws a constraint violation

Step 2: Retry logic in application

def create_short_url(long_url): for attempt in range(3): short_key = generate_random_key(7) try: db.insert(short_key=short_key, long_url=long_url) return short_key except UniqueConstraintViolation: continue # Try again with a new key raise Exception("Failed after 3 attempts")

That's it! Simple and effective.

But wait — what if you use auto-increment instead of random?

Then the race condition shifts:

What to write in your draft

"For ID generation, I'll use a random 7-character base62 string. On collision (caught by the unique constraint on short_key), the service retries with a new random key up to 3 times. Since 62^7 ≈ 3.5 trillion combinations, collisions are extremely rare in practice."

Suggested components for TinyURL

Start with Component 1: ID Generation

Write about:

• Algorithm — Base62 encoding (0-9, a-z, A-Z) or Base64
• How to generate unique IDs — Options:
  • Auto-increment + Base62 (simple, but predictable)
  • Snowflake-style ID (distributed, no single point of failure)
  • Random string (e.g., 7 chars of base62 = ~3.5 trillion combinations)
• Collision handling — What if two users generate the same ID? (unique constraint + retry)
• Hard to guess — Random vs sequential (security concern)

Try writing something like:

"For ID generation, I'll use a random 7-character base62 string. That gives 62^7 ≈ 3.5 trillion unique keys — more than enough. On collision (caught by unique constraint), I retry with a new random string. This is simple, distributed-friendly, and hard to guess."