Requirements

Functional Requirements:

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

1) user should be able to input a long url and get a short url in exchange

2) user should be able to see the history of old inputs

3) redirection should happen with a 302 http method

Non-Functional Requirements:

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

1) system should be able to handle hot spots for a viral short url 10M clicks per second

2) availability and partition tolerance is important and consistency can be eventual

3) Low redirect latency p99 < 100ms

Capacity Estimation

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

1M DAUs and let's say 1% are actively using to create short url and 10% people are redirecting at a time means 100k reads at a time max which means that we might not be needing a write heavy but ready should be taken care of

the qps would be 10k creates a day roughly 10 write a minute

reads would be 1m readys a day 12 reads a second

assuming each row is a short code + long url and some metdata 500 bytes

10K per day we need 5MB a dat 2 GB per year

for growth projections we can use a 2x multiplier

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

GET API

/?longUrl=https://codemia.io/system-design/designing-a-simple-url-shortening-service-a-tinyURL-approach

Response 201 OK

{

shorturl: https://test.io/xyrbuw

}

GET /{shortCode} → 302 Found Location: https://original-long-url.com/...

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.

Write path (creating a short URL)

1. Client sends a request to the API Gateway, which handles auth and rate limiting.
2. The API Gateway forwards the request to the short URL generation service.
3. That service gets a unique ID from Zookeeper (used for coordinating unique ID generation across distributed nodes).
4. The generated short URL mapping is written to the leader (write) database, which is indexed by that ID.
5. From there, an async call sends data to the analytics service (for tracking/metrics without blocking the write path).

Read path (resolving a short URL)

1. Client requests also route through the API Gateway, which forwards them to the read service.
2. The read service first checks the cache:
   • Cache hit → the cached result is returned directly back to the read service (fast path).
   • Cache miss → the request falls through to the database read replicas.
3. The Database Read node sits in front of additional Database replicas — this is a read-replica setup, meaning read traffic is distributed across multiple copies of the database to scale read throughput independently from writes.
4. Read activity also feeds into analytics asynchronously, same as the write path.

Overall architecture pattern

This follows a classic CQRS-like split (Command Query Responsibility Segregation):

• Writes go to a single leader database (ensuring consistency for new URL creation).
• Reads are offloaded to a cache layer first, then replica databases if needed — a common pattern to handle the heavy read-to-write ratio typical of URL shorteners (far more people click short links than create them).
• Analytics is decoupled from the main request path via async calls, so it doesn't slow down either reads or writes.
• Zookeeper is used specifically to generate globally unique, non-colliding IDs across potentially many instances of the generation service running concurrently.

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

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.