Requirements

Functional Requirements:

generate a unique, compact Base62 short code size 7 chars

URLs live forever

REST API call to retrieve/redirect

accept a long URL input

optional API-key auth on creation; open anonymous redirects.

Given a short code, redirect the user to the original long URL (verifying the redirect path is unauthenticated and cache-served

Non-Functional Requirements:

scale horizontally to billions of redirects/day.

1:100 read:write ratio

Redirect latency p99 < 100ms

Create latency p99 < 500ms is fine

Observability: monitor redirect latency (p99), cache hit ratio, and error rate; alert on SLO breaches.

redirects keep working even if a single region or database fails, via multi-region replicated reads.

Capacity Estimation

10–50M active users daily.

API Design

POST /tiny-url

body :

{

"url": "URL"

}

Responses:

201

{

"url": "URL",

"tinyUrl": "TINY_URL"

}

500

Some internal error code

GET /tiny-url/{URL}

Responses:

302

Location: "TINY_URL"

500

Some internal error code

High-Level Design

• Entry layer: Reverse proxy/edge terminates TLS, routes, and load-balances requests to the services.
• Write path (Command Server): handles POST /tiny-url, generates a unique Base62 code, persists the mapping to the store under strong consistency. CDC propagates new rows to Redis.
• Read path (Query Server): handles GET /{shortCode}, checks Redis first; on a hit returns 302; on a miss reads from the store by PK, populates Redis, then returns 302.
• Identifier generation: application-level Base62 over a counter/random, unique by virtue of being the PK.
• Storage: DynamoDB/Cassandra — durable source of truth, auto-sharding, multi-region replication.
• Caching: Redis — cuts redirect latency and DB load; ephemeral, never source of truth.
• Why two services: read:write is 100:1; the read path stays thin and latency-critical while the write path owns code generation and consistent writes

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

i'll use noSQL as:

my access is pure key-valeu retrieval

data is inserted and never updated later on and single entity has no relationships

sharding is automatic in DynamoDB/Cassandra = partition key is the shard and nodes rebalance themselves

multi-region replication is a config flag

Write throughput scales linearly as i add more replicas

URL table

TINY_URL::String PK

URL::String

CREATED_AT::Timestamp

tiny_url is used as shardid

tiny_url is calculated at application level and since is PK it must be unique. tiny_url is the short code is generated at the application level (Base62 over a counter/random) and is globally unique by virtue of being the PK.

strong consistency on writes and weak consistency on reads.

Data is denormalized to privilege reads

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.

Reverse Proxy deals with TLS and for post with authentication.

there are 2 servers: command to deal with post requests and query server to deal with gets. command server hashes url and stores in key-value DB the url and tinyurl. Via CDC the new urls are replicated in redis to improve performance. 2 components allows for each to be developed to be more performant. Query Server checks redis first and in case of cache miss goes into DB. Cache miss should only occur in the beggining or when old items are evicted from redis