User needs to be able to paste a url and receive a shortened url
A user clicking the shortened url needs to be taken to the original url
Non-Functional:
1 million users
10 million write requests per month
1 billion read requests per month
Capacity estimation
roughly 2.5 million seconds per month
4 writes per second
400 reads per second
URL is roughly 500 bytes
shortened url roughly 100 bytes
roughly 5GB of data stored per month
API design
write api - takes input of a URL and shortens it using hashing to a shorter url. Checks if that hash already exists in the database. If it does not, we store in a key value pair where the shortened URL is the key and the original url is the Value
Read API - takes an input of a URL. Attempts to find a matching key of the input URL and redirects to the original URL stored in the value
Database design
SQL relational database of key-value mappings.
High-level design
Client sends either a read or write request to our reverse proxy
The reverse proxy handles load balancing and caches frequent requests
the reverse proxy sends requests not in the cache to the server
server - receives request over https
write api stores our key value mapping of the shortened url and the original url in a SQL database
read api first attempts to find the key value mapping in the cache, if it does not exist in the cache we go to read from the database
Request flows
Client sends either a read or write request to our reverse proxy
The reverse proxy handles load balancing and caches frequent requests
the reverse proxy sends requests not in the cache to the server
server - receives request over https
write api stores our key value mapping of the shortened url and the original url in a SQL database
read api first attempts to find the key value mapping in the cache, if it does not exist in the cache we go to read from the database
Detailed component design
Client sends either a read or write request to our reverse proxy
The reverse proxy handles load balancing and caches frequent requests
the reverse proxy sends requests not in the cache to the server
server - receives request over https
write api stores our key value mapping of the shortened url and the original url in a SQL database
read api first attempts to find the key value mapping in the cache, if it does not exist in the cache we go to read from the database
Trade offs/Tech choices
NoSQL over SQL database is chosen here because of NoSQL's K/V storing efficiency. They can also provide low latency access for reads and writes
Failure scenarios/bottlenecks
Huge increase in traffic from our client to our server could overwhelm our server with requests
Future improvements
Adding multiple servers and loadbalancers to spread out requests