Designing A Simple Url Shortening Service A TinyURL Approach - System Design

Requirements

Functional Requirements:

Create a short URL for a given long URL.
Return the long URL associated with a given short URL.
URLs should be unique

Extra:

URL custom expiry dates

URL user rights

Non-Functional Requirements:

List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...

One link should refer to exactly 1 website

We need maitain HA of the service and also Consistency for the URL data. Redirection should be fast < 500ms.

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 /shortener

//JWT token for auth

{

"URL":"https://website.io/"

"ExpiryDate":"06-05-2026"

"CustomAlias":"MyLinkIO"

}

return -> "short_link":"/MyLinkIO" / or default "short_link":"a8Jo9"

or ERROR -> CustomAlias used.

GET /a8jo9

REDIRECT 301 -> https://website.io/

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.

Client will access the API gateway (which can server as Load balancer and rate limiter) then request goes to Shortening service. Shortening service will simply increment some ID and use Base decoding with low_case Upper_case letters and digits to generate a unique small link. Only with 26 upp\low then 10 digits -> 4-5 letter is enough already to server billions of links.

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. We will use PostgreSQL to make sure our links are oinned to exactly to 1 website, also later will be essencial have ACID for user rights management. Our system will be read heavy, so we can implement Master-slave replication and increase reading throughput, also we will be able do consistent hashing. and sharding if needed. for main service we will have Redis cache and we can use LIFO logic to exlude less popular links from the cache.