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

4) user is able to get the long url associated with the generated short url

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

4) high availability 99.9% (Three Nines)

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 request to a cdn.
2. CDN redirects a request to the API Gateway, which handles auth and rate limiting.
3. The API Gateway forwards the request to the short URL generation service.
4. That service gets a unique ID from Zookeeper (used for coordinating unique ID generation across distributed nodes).
5. The generated short URL mapping is written to the leader (write) database, which is indexed by that ID.
6. 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

Data Model for URL Shortener

Main Entities

1. URL (the core mapping)

This is the central entity — the short code → long URL mapping.

Access pattern this entity serves: the read path does a single point lookup by short_code — this is the hottest, most latency-sensitive query in the whole system.

2. ClickAnalytics (per-click event log)

Captures each redirect event, feeding the async analytics pipeline shown in the diagram.

Access pattern: write-heavy, append-only, almost never updated, queried later in aggregate (e.g., "clicks per day," "top referrers") rather than by individual row lookup.

3. User (optional, if the system supports accounts)

4. IDAllocation (Zookeeper-adjacent, if modeled explicitly)

Not always a persisted "entity" in the traditional sense — Zookeeper here is more of a coordination service — but conceptually:

Relationships

• One User can create many URLs (one-to-many).
• One URL can have many ClickAnalytics events (one-to-many) — every redirect generates a new event row, never updates an existing one.
• There is no relationship requiring joins on the hot read path — short_code → long_url is a standalone lookup, which is intentional and important (see below).

Database Choice: SQL vs NoSQL

Recommendation: Split storage by access pattern — NoSQL (key-value) for the URL mapping, and a column-oriented / time-series-friendly store for analytics.

Why NoSQL (key-value store, e.g., DynamoDB, Cassandra) for the URL table

Reasoning based on the diagram's access patterns:

1. Access shape is pure key lookup. The read service's whole job is "given short_code, return long_url, as fast as possible." There's no need for joins, complex filtering, or relational integrity here — this is the textbook use case for a key-value store, where short_code is the partition key.
2. Massive read-to-write skew. URL shorteners are read-dominated (far more clicks than creations) — exactly matches the diagram's emphasis on a cache layer + read replicas in front of the database. Key-value stores like DynamoDB scale horizontally for this kind of read-heavy, simple-lookup traffic more naturally than a single relational leader can.
3. Horizontal scalability without resharding pain. As the dataset grows into billions of short URLs, a NoSQL store partitions cleanly by short_code hash, whereas a single SQL leader (as shown in the diagram — "leader and write DB") becomes a write bottleneck and eventually needs manual sharding logic bolted on.
4. No strong need for multi-row transactions. Creating a URL entry is a single-row write; there's no multi-entity transaction requirement (e.g., no "update URL and User balance atomically" scenario) that would push you toward SQL's ACID guarantees.

Why the diagram's actual leader/replica setup could also just be SQL — and when that's fine

If the ID generation via Zookeeper already guarantees strict uniqueness before insert, a single relational leader database with read replicas (as literally drawn) works too, since:

• Writes are simple single-row inserts (no complex transactions needed anyway).
• Reads scale out via replicas + cache, matching the diagram exactly.
• SQL gives you easy secondary indexing (e.g., querying "all URLs created by user X") if that's a required feature.

In short: NoSQL is the "purist" choice for pure key-value redirect lookups at extreme scale; a well-cached SQL leader/replica setup (exactly as drawn) is a perfectly reasonable, simpler alternative if scale is more moderate or relational features like per-user URL listings matter.

Why NoSQL (wide-column / time-series style, e.g., Cassandra, or a data warehouse like BigQuery) for ClickAnalytics

1. Append-only, extremely high write volume. Every single redirect creates a new row — this is a write-throughput problem, not a consistency problem. Wide-column stores (Cassandra, ScyllaDB) or log-oriented pipelines (Kafka → data warehouse) are built exactly for this: high-velocity, immutable event ingestion.
2. Query pattern is aggregate, not point-lookup. Analytics queries look like "clicks per day for this URL over the last month," which favors column-oriented storage (fast for scanning/aggregating single columns across huge row counts) over row-oriented SQL tables.
3. Matches the diagram's explicit "async" write path. Since analytics writes are already decoupled and asynchronous (not on the critical request path), the system can tolerate eventual consistency here — you don't need the same strict guarantees you might want for the URL mapping itself. This further supports a NoSQL or streaming-based approach (e.g., write to Kafka, batch into a columnar analytics store).

Summary Table

The core justification throughout: let the query pattern drive the storage choice — the diagram already hints at this by separating cache/read-replicas (optimized for lookup speed) from the async analytics pipeline (optimized for write throughput), so the data model should mirror that same split rather than forcing everything into one database type.

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.

2. Caching Redis sits in front of the read DB; CDN at the edge. A viral link serves from CDN → Redis → replica, so origin isn't hit. On miss/TTL expiry: fetch from read replica, serve the 302, write back to cache. On delete/update: purge the Redis key + CDN invalidate. Eviction: LRU with a TTL to balance freshness vs. memory.

3. Partitioning Shard by hash(short_id) % N → a redirect routes to one shard, no scatter. Consistent hashing spreads traffic evenly. Hot IDs don't overload a shard because cache/CDN absorb the read load before the shard sees it.