Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

Given a short Url redirect to original long url

Given a long url generate short url n redirect

Generating alias

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

Scale: how many URLs created/day, how many redirects/day

redirect should be fast

reads more less writes sort of 100:1 ratio

should redirects basically never go down

a stored short URL should never get lost

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

• Writes: 100M new URLs/day (100M users × ~1 URL each)
• Reads: 100:1 ratio → 10B redirects/day
• Writes: 100M ÷ 86,400s ≈ 1,200 QPS
• Reads: 10B ÷ 86,400s ≈ 116,000 QPS

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

Write flow (create short URL): Client → Load Balancer → App Server → ID Generator (get next unique number) → base62-encode it → store {short_code: long_url} in DynamoDB → return the short URL to the client

Read flow (redirect): Client → Load Balancer → App Server → check Redis cache for short_code → if hit, return long_url immediately (302 redirect) → if miss, query DynamoDB, populate cache, then return the redirect

POST /api/v1/shorten

Request: { "long_url": "..." }

Response (201): { "short_url": "...", "short_code": "..." }

GET /{short_code}

Response: 302 redirect → Location:

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.

when ever a user makes a request at client app/browser i place a loadbalancer which will efficently distributes the loads among the application server can be horizontal scabable depending on the traffic and then Id generator service api call wil be made n depending read call or write call the process will take place for example if reads I place a cache of elasticcache (redis) bcoz we need quicker reads than writing no joins are required and needs ot be fast if not in cache the database will be accessed n brought into the cache similarly for writes the write api call will call id generator n stores writes the new short url against orginal one using Base62 endoing which works using new code generator using increment 1 concept and stores into dynamo db bcoz these are key value pairs n again we dont need much of joins and all n writes can take time as its more reass than write system we can add additional CDN in front just incase of far away region issue

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

Dynamo DB for all reads/writes I will use elastic cache redis for hot links read which will improve the 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.

Load Balancer

• Job: distributes incoming requests across multiple app server instances so no single server gets overwhelmed
• Why needed: enables horizontal scaling — as traffic grows, you add more app servers behind it rather than making one server bigger
• AWS mapping: Application Load Balancer (ALB)

2. Application Servers

• Job: stateless compute layer that handles the actual request logic — validates input, talks to the ID Generator on writes, checks cache/DB on reads
• Why stateless matters: any server can handle any request, which is what makes horizontal scaling and auto-scaling possible — no server holds session-specific data
• AWS mapping: given our earlier discussion, this fits well on Lambda (unpredictable traffic, minimize idle cost) or ECS/EKS if you expect steady baseline load

3. ID Generator Service

• Job: produces a guaranteed-unique, incrementing number for every new short URL created, which then gets base62-encoded into the short code
• Why it's its own component, not just logic inside the app server: if you have multiple app servers creating URLs simultaneously, they'd race to generate the same number unless there's one authoritative source of truth for "what's the next number." This is a classic distributed coordination problem.
• Real implementation options: a dedicated counter service backed by a strongly-consistent store, or pre-allocating ID ranges to each app server (e.g., server A gets 1-1000, server B gets 1001-2000) to avoid a bottleneck on every single write

4. Cache Layer (Redis/ElastiCache)

• Job: stores the hottest short_code → long_url mappings in memory, so repeated reads for popular links don't hit the database every time
• Why needed: given our 100:1 read-heavy ratio and the "hot key" problem (viral links), this is what keeps read latency low and protects the database from load spikes
• Pattern used: cache-aside — check cache first, on miss go to DB and populate cache

5. Database (DynamoDB)

• Job: the durable source of truth for every short_code → long_url mapping, ever created
• Why DynamoDB specifically: simple key-value access pattern, no joins needed, needs to scale to potentially billions of rows with fast, predictable reads — exactly DynamoDB's sweet spot

6. CDN (CloudFront) — optional/enhancement layer

• Job: caches redirect responses at edge locations geographically close to users, reducing round-trip latency for users far from your primary AWS region
• Why it's separate from Redis: Redis solves "which links are hot," CDN solves "where is the user physically located" — two different latency problems