Requirements

Functional Requirements:

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

• Create short URL — given a long URL, generate a unique short code (e.g., tinyurl.com/aB3xK9) and return the short link.
• Redirect — given a short code, resolve it to the original long URL and redirect the user (HTTP 301/302).
• Custom aliases (optional/nice-to-have) — let users pick their own short code.
• Expiration (optional) — links can have a TTL or default expiry.
• Analytics (optional) — track click counts per short link.
• Idempotency — optionally return the same short code if the same long URL is submitted again.

Non-Functional Requirements:

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

• High availability — redirects must work ~24/7; a redirect outage breaks every shared link. Target 99.99% uptime.
• Low redirect latency — redirects should return in <100ms
• Scalability — support millions of new URLs/day and billions of redirects/day; scale horizontally.
• Read-heavy — redirect traffic >> creation traffic (often 100:1 or more); optimize the read path.
• Durability — once created, a mapping must never be lost (links are shared and must persist).
• Uniqueness — no two long URLs may collide on the same short code.
• Short codes — keep them as short as possible (e.g., 6–7 chars using base62).

Capacity Estimation

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

• Assuming 100M new URL/day; read:write ≈ 100:1 -> 10B reads/day
• Write QPS: 100M/86400=1157/s
• Read QPS= 10B/86400=115000/s
• Keyspace: 100M url/day x 365 x 10 years = 365B URL's. Base62 = [a-z][A-Z][0-9]. 62^N gives length. 62^7=3.5T.
• Storage: ≈ 500 byte (url+short code + metadata) x 100M = 50 GB/day -> 18.2T/year.
• Growth: 20% -> plan sharding well before that

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

• POST /v1/short

Body: { "longUrl": "url", "customAlias": "optional", "expiry":"optional"}

201 Created -> {"shortUrl":"tinyUrl/ajk134B", "shortCode":"ajk134B"}

• GET /v1/{shortCode}

301/302 -> Location: https://original-long-url...

404 -> Not found

410 Gone -> expired

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.

• LB + API gateway: handle routing, TLS, rate limiting
• Shortener service: accept long URL, request unique ID from generator and stores mapping in DB (here we could also check for duplicates)
• Redirect service: look up cache first, then DB, then redirect
• ID generator: guarantees unique codes
• DB/redis: DB stores persistently, redis absorbs the read load

Database Design

Database choice: DynamoDB or Postgres + Citus for sharding across read replicas.

Consistency: Creation needs strong consistency. Reads accept eventual consistency. On DynamoDB is easily done with ConsistentRead=True. On postgres + Citus we need different connection on Redirect/Shortener service.

DynamoDB pay per request/ Postgres per infrasctructure.

Redis absorbs the DB access so it makes DynamoDB viable.

• url_mappings
  • shortCode varchar(7) not null PK
  • long_url varchar(200) not null
  • user_id integer not null
  • created timestamp not null
  • expire timestamp null

PARTITION BY hash(shortCode)

• users
  • user_id integer not null PK
  • email varchar(100) not null

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.

• ID Generation:
  • Random base62(7) → 3.5T space, unguessable, no central bottleneck.
  • Collision-safety: conditional insert (attribute_not_exists / ON CONFLICT DO NOTHING) + retry on conflict.
  • No SPOF — the code lives in your insert, not a shared counter.
• Caching
  • What: short_code → long_url in Redis, in front of the DB.
  • Why: absorbs the 115K read QPS; ~95% hit rate keeps DB load and DynamoDB cost down.
  • Hit/miss: hit → return 301; miss → DB → populate → return.
  • Failure: cache down → thundering herd on DB → mitigate with request coalescing; viral link (one hot key) → solve with CDN, not bigger DB.