Loading...
List the key functional requirements for the system (Ask the AI for hints if stuck)...
1.Url shorting
2.Analytics for urls visits
3.Redirection of short url to main website
List the key non-functional requirements (performance, scalability, reliability, etc.)...
1.High Availability : Its a critical service as website view depends on this.
2.Scalable :The System should be Horizontal Scalability.
3.Unique ID Generation for short url.
4.low latency in redirection flow.
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
MAU=100M
DAU=100*0.3 =30M
Get URL
100:1 read write ration im assuming this as url is used more than create
700*100= 70k read/second
Make URL
1 user can make 2 url a day
-30M*2= 60M%86400(seconds in day)=700 write/sec
worst case 700*.3=2100 write/sec
Request per seconds are 70.7k
Storage
Data we will store
-id
-url
-uuid
-created_at
-status
1Write =500byte
500byte * 60M =30GB
30* 365=11TB year
11*5 =55TB
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...
API Design
1. Redirect to main url
method: Get
Url : baseurk/{uuid}
response
http:302(Redirect)
header
redirection-url:{original_url}
2.create short url
Method:Post
path: /short/url
request
{
"url":"www.google.com"
}
response
httpcode 201
body:
{
"short-url":"www.tinayurl/12dadad"
}
Admin-Side
3.Fetch All short url
method: Get
Url : /short/urls
response
http:200
header
{
"urls":[
{
"id":""
"url":"",
"short-url"
}
]
}
4.View url clicks
method: Get
Url : /short/url/{id}/@duration=1m
response
http:200
header
{
"id":""
"url":"",
"total-clicks":100
}
Client: In this case its going to be our web-application.
Load Balancer: we will use load balancer here to distribute load in Url shorting service node.This service is stateless as we can do horizontal scaling here.
Url shorting service: The purpose of this service to short url and host out api for url redirection.plus this will generate 7 digit shortCode for every url.
Postgres:This will works like storage layer here and we will store shortCode and url mapping postgres.
Redis: We will use CDC to make redis cache from postgres we can use devizium. the perpouse of this to sever hight read path.
Flink: We will use flink as aggregation platform for url clicks and data leak can pull from here.
data lake : we will store aggregated url click data here client dashboard.
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...
we will use postgres here .
url_mapping
-id (postgres sequence )
-url text
-short_code varchar(7)
-created_at timestamp
-status Text( ACTIVE,DISABLED)
-expiries_at
In Redis we will us HashSets will space name of urls
inside they key will be short_code value is url and it will give us flexibity to add ttl on redis.
short code
we can generate 64-bit unsigned integer (a big number) that mathematically guarantees uniqueness across thousands of servers.Once that large number is generated, it is passed through a Base62 encoder which compresses that massive number down into exactly an 8-character string (0-9, a-z, A-Z).
Component Bits Allocated What it does / Maximum Range
Timestamp 37 Bits Tracks milliseconds elapsed since a custom epoch (e.g., Jan 1, 2026). 37 bits allows the system to run for approx. 4.3 years before wrapping around.
Datacenter ID 3 Bits Allows up to 8 independent datacenters globally.
Worker/Machine ID 4 Bits Allows up to 16 separate server nodes per datacenter.
Sequence Counter 4 Bits A local counter that resets to 0 every millisecond. Allows 16 unique URLs per millisecond per server.
Total 48 Bits Used 2⁴⁸ equals 281 trillion. By stripping down the timestamp slightly, we hit a maximum number that perfectly translates to an 8-character string.
Index strategy
we will make index on short_code.
Partition key
we can do Partition on created_at.
Create (write): Strong consistency. The short code must be durable and unique the instant it's returned — enforced with a transaction + unique constraint on short_code, so two concurrent creates can't collide.
Redirect (read): Eventual consistency is acceptable. If Redis or a replica lags a few milliseconds, the only effect is a transient 404 on a brand-new link — never data corruption. So the read path does not need to be strongly consistent.
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.
ID-Generation:
we can generate 48-bit unsigned integer (a big number) that mathematically guarantees uniqueness across thousands of servers.Once that large number is generated, it is passed through a Base62 encoder which compresses that massive number down into exactly an 8-character string (0-9, a-z, A-Z).
Total: 48 Bits Used 2⁴⁸ equals 281 trillion. By stripping down the timestamp slightly, we hit a maximum number that perfectly translates to an 8-character string.
Rate limiting :
We can use rate limiting service based on IP.
Partition or sharding:
we will do sharding in postrgres based on shortcode and use citus for it .
Cacheing:
we will use redis as cacheing service and use cdc to sync this along with ttl. In Redis we will us HashSets will space name of urls
inside they key will be short_code value is url and it will give us flexibity to add ttl on redis.