Requirements


Functional Requirements:


  • Create a short URL for a given long URL.
  • Return the long URL associated with a given short URL.
  • Have a expiration date TTL



Non-Functional Requirements:


    • Latency & PerformanceThe system should provide very low read latency to ensure a fast user experience.
    • Write latency can be relatively higher but should remain within acceptable limits.
    • Availability & ScalabilityThe system must be highly available with minimal downtime.
    • It should support horizontal scaling to handle increasing traffic and data volume.
    • Data Consistency & UniquenessThe system should ensure that duplicate entries for the same URL are not created.
    • Appropriate mechanisms (Snowflake ID genartion +Base62) should be used to enforce uniqueness.
    • Data Retention & ExpiryEach record should support a configurable expiration time, with a default of 10 years.
    • The system should automatically delete expired records without manual intervention.
    • ThroughputThe system should efficiently handle high read-heavy workloads (e.g., 100:1 read/write ratio).
    • It must sustain high QPS while maintaining low latency.



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 request -> returns 201 created status in case of success, returns 409 conflict that record already exists.
  • Get request -> for shortened URL, the full URL should be returned which it represents.

it returns 302 redirect request

  • Delete request -> 200 for successful deletion and 404 for not found.


High-Level Design

Read Flow:

When a client makes a request to access a shortened URL, the request is first resolved via DNS to reach the appropriate service endpoint.

The request is routed through an API Gateway, which is responsible for:

  • Rate limiting
  • IP whitelisting / security checks
  • Basic request validation and routing

The API Gateway forwards the request to the application server.

The application server performs:

  • Cache Lookup (Redis):
    • If the short URL mapping is found in cache → return the original (long) URL immediately.
  • Database Lookup (Cache Miss):
    • If not found in cache → query the database
    • Store the result back in Redis (cache warm-up)
    • Return the long URL to the client

Write Flow

The client sends a request to create a short URL via the API Gateway.

The API Gateway performs:

  • Authentication (if required)
  • Rate limiting
  • Request validation

The request is forwarded to the application server.

The application server:

  • Generates a unique ID using a Snowflake-style generator
  • Encodes the ID using Base62 to create a short URL
  • Stores the mapping (short URL → long URL) in the database

A success response containing the shortened URL is returned to the client.




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.

  • It is a read extensive structure, normally 100:1 for read vs write.
  • Consistency vs Availability : The system should be highly available, as per assumption that once the shortened URL is created, it won't be immediately shared to use.
  • The expiration date is set as 10 years by default, so we need to store the shortened URLs for at-least 10 years.
  • With 1 million QPS, the write requests would be 1000 per second, so for 10 years , around 3 trillions records.
  • the characters which can be used for the shortened URL would be [0-9][A-Z][a-z], totalling 62 characters, so the shortened URL should be characters as 62^7 so will be 3.15 trillion records supported.


  • The client give GET request, there is caching at DNS level and Redis level, if there is caching miss, then only hits DB.