Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.

Non-Functional Requirements:

High availability — if the system goes down, every short link on the internet breaks. Needs 99.9%+ uptime.

Low latency — redirects should be near instant, under 100ms. Nobody should notice the redirect happening.

Scalability — needs to handle ~11,500 redirect requests per second and grow with traffic spikes.

Durability — once a short URL is created it should never be lost. Data needs to be replicated.

• Read optimized — redirects

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

The api design will require 2 things

• POST Which will send the url to the server to be turned into a short url
• GET which will happen when the user clicks on a shortened url and the original url is needed

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.

"The system has five core components. The client sends requests to a load balancer, which distributes traffic across multiple application servers. When a redirect request comes in, the server checks the cache first. If the short code is found, it returns the original URL immediately without touching the database. If not, it queries the primary database, stores the result in cache, and returns the URL. A database replica sits alongside the primary for redundancy and to handle read traffic."

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 uses least connections algorithm — each new request goes to whichever server currently has the fewest active connections. This handles uneven request loads better than round robin.

Cache (Redis) sits between the app servers and database. On every redirect request the server checks Redis for the short code first. On a hit it returns the original URL instantly, never touching the database. On a miss it fetches from the database, stores it in Redis with a 24 hour TTL, then returns it. Since redirects are 10x more common than writes, caching dramatically reduces database load.

Database is a SQL database with a single table keyed on short code. The primary handles writes, the replica handles reads and provides redundancy. If the primary goes down the replica is promoted automatically."