Requirements

Functional Requirements:

1. User can create short url
2. User should be redirected to original url when he hits short url.
3. User should see analytics (clicks) for a url in dashboard

Non-Functional Requirements:

1. Highly available
2. Low latency (real time)
3. Short and unique url

Capacity Estimation

Assume 100M daily active users.

Since system will be read heavy, so consider 1000:1 read - write ratio.

So read = 100M /day = 10000 req/sec

write = 100K / day = 10 req/sec

For storage, lets assume we should be able to store 1B urls.

To acheive 1B urls -> we would need 10000 days = ~25 years.

And lets assume , short url = 10B, long url = 100B, userId -> 10B, expiration date = 10B

So for 1B urls -> 1B x 130B = 10^11 B = 130GB

API Design

// urls

• GET /url/{short_url}

response: 302 redirect , Location: {Original_url}

• DELETE /url/{short_url}

expire the url and delete the mapping

• POST /url

body: {url: {url}, custom_alias: {custom_name}, expiration_date: {date}

// Analytics

Get /url/analytics/{short_url}

response: {count: {number}, last clicked: {date}}

High-Level Design

Okay Sar for high level design it should be like any client or and user will had the URL!

To create a short URL so it will hit our APS server through DNS resolve. And after that in our APS server we will be generating that short code. Will be create add in the maping into our database it is read having so we should use and we do not have any answer relationship so you can use no data? Scenario is whenever user heads to. The short URL. So it lands to our IPS server so for that shot you are always search in our database and we receive the original URL responde with 302 redirect and the location is said to be the original URL hair we are not using three not one because three not one has maximum cache set so we will not be receiving request to our. After that so to have controlled. On our Request we will be using 302.

And same for getting analytics of any URL, same architecture would be followed.

Database Design

url: {

short_url: string; // partition key

original_url: string;

expiration_date: date;

}

// creation: strong consistency

// read: eventual consistency (To get high availability)

analytics: {

short_url: string;

count: number;

last_clicked: date; }

Detailed Component Design

Yeah so moving into detail design so I would be leaning here how the system should behave if there is instant bus of traffic or many traffic much traffic so first component is like API gateway or not balance sir so this will be the. Traffic Long URL for a short URL it will hit the load balance sir will get one server based on other based on route or based on current traffic on server.

For cache, we are using redis and since it is in memory , It can handle like large traffic.

Database we are using is dyanmoDb where scaling is auto managed by aws. If we would have used another DB like RDS databases, we would need read replicas for the DB to serve high traffic with low latency.

Show the whole flow is whenever any client hits the short URL in web browser. The request goes to nearest as location and it's check the CDM if there is any mapping available in cdn it is directly return from cdn and is getting redirected to the original URL if it is not present in the serial it then checks it then gets redirected to load balance sir and load balance the traffic to available server then the server check. Kaise and check if mapping is available for short URL if it is available it returns the cache as a redirect if it is not present there it then check the dynamo DB. Where get the mapping through short URL and get the original it then rights back to the cache and after that it returns to the user 302 redirect with location as original URL? Another case is user wants to delete the URL whenever user hit the URL to delete the short your mapping it receives into the. Server and After that what it does this it first delete Kaise delete flow.

Also Create floor would be similar in Shimla architecture where client to the creative viral in IT lens to the Load Balancer after that goes to the server where server creates the code unique code that is explained in the high level design so after that like we need to make sure that concurrent creates are colleges safe so. Since we are using incremental counter with Central threaded so it avoid concurrent rights and whenever any concurrent request come it will just read it sequentially and will avoid the concurrent right in this way we will get always unique counter and then after that we can in code the unique counter with base 62 R to get reliable. Code and we can also add some salt over there so that any random cases cannot reach. So in this way we can have coalition safe and random case proof.

And also to be full proof from abuse, we can add a rate limiter where we can have rate limit per ip.