Designing URL Shortener
Introduction and Features
Problem Statement
Architecture and Components
Low-Level Design
Different Approaches to Store URL
More Interview Problems
System Design
Architecture and Components


Architecture and Components

footer line


Clients and Web Server


Web Browser/ Mobile apps are the service provider which will communicate to our backend services using HTTP/HTTPS protocol. 

We would need multiple web-server to ensure high availability and scaling horizontally, A load balancer will be required to distribute all requests evenly to different servers.


Displaying img 9.jpg


Requests and Storage


Every user uses shorteners when they are going to use URL multiple times and redirection also happens most of the time, so Read operations on our DB are much more than write operation, on an average considerably it’s 1:100, So our system is going to be read-heavy system. 
Let’s say we get 20 URL generation requests per second So on average we will get 30days * 24H * 3600sec * 20 = ~50M write requests per month. And 5 Billion read requests per month, So we would be needing good storage and caching system for this.

We assumed we will be storing 50M URLs every month and each object will take around 100 bytes, So 1 TB storage is enough for us for storing data for 5 years at the current rate. 





We would be requiring Cache for popular URLs let’s say 20% of total requests. So for that purpose, we would need 20 GB of memory for caching. Introducing Caching we can also scale our read queries. We can simply implement an LRU(least recently used) approach for evicting cache policy.
We also need to update Cache if many requests start coming for any new URL, so we need to update a cache for that new entry.