Requirements

Functional Requirements:

1. Server should have an api to let client post the original URL.
2. Server should have a solid way to convert a long URL into a TinyURL.
3. Server should also have the ability to convert a TinyURL back to original URL.
4. Once user clicks on the TinyURL, server should know what's the original URL and help redirect.

Non-Functional Requirements:

Low redirect latency: The target redirect latency is P99 < 50ms, the database operation could take a lot of time, current idea is to cache the frequently used TinyURL.

High availability: The server needs to have at lease 2 pods, if the main pod is down, the sub pod can support.

Horizontal scalability: It could be over 10,000 clients requesting server at the same, the server should be deployed on multiple pods, and api call can by dynamically distributed.

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

Two APIs are needed:

• POST /create-tiny-url

Request body:

{

"url":

}

Response body:

{

"short_url":

}

• GET /{short_url}

Response: 302 Found

Location: https://tiny-url.com

• PUT /{short_url} — update the target long URL
• DELETE /{short_url} — remove a short link

High-Level Design

1. Entry layer - load balancer / API gateway
2. Write path service: When POST /create-tiny-url is called, this service will generate a base64 encoded string as short URL id.
3. Read path service: Handles GET /{short_url} redirecting short URLs to long URLs.
4. ID generation: Create base64 encoded string.
5. Storage layer: Store the url mapping in database, both short url and long url should be primary key.
6. Caching layer: Cache the latest requested url with TTL.

Database Design

Only one table is needed, the entity design can be:

{

id: ,

short_url: ,

original_url: ,

updatedAt: ,

updatedBy?:

}

The primary key will be id and short_url, we should add index for both short_url and original_url. When user tries to update the original url, it'll be convinent to find and update.

Consistency:

Writes (create): Strong consistency to let user always see the most recent write.

Read (read): Eventual consistency to give quick response.

Partition:

Partition key: short_url

Number of shards: 3 shards

Re-sharding: Managed DBs can handle re-sharding automatically.

Detailed Component Design

ID Generation Service

Functionalities:

• First use Snowflake to create a unique ID, then use base62 encoding to create short URL based the URL in request.
• Write the new short URL record in DB.

Redirect Service

Functionalities:

• Find the short URL corresponding original URL and send 302 response

Cache Layer

Create a cache service, using LRU eviction policy, to cache the latest 100 requests. If the cache missed, find the record in DB and cache it.

Add read replicas per shard.

Rate Limiter

Use Token Bucket to prevent abuse.