1.url shortener
2.Redirect
1.ID Generator
2.Shortener
3.Validate url
4.Redirect 302
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
1.api/GET/redirect
2.api/POST/shorten
3.api/POST/generate(only api/shorten call this)
1.n servers(n - decided according to the scale)
2.Microservices: ID Generator,Shortener,Redirect
3.Load Balancer - to route requests to the server with low load and to verify the health of the severs
4.Cache - stores the frequently requested urls as key value pairs.(Redis)
5.Databases -(RDBMS - SQL).Relational DB is best for this problem as the data is structured. multiple master-slave replication model.
6.Logging - Automated logging which checks the DB and server logs.It helps to identify failures.
7.Automation - When a server fails,the traffic gets routed to other available servers until it is fixed.
Master-Slave Model
1.Master - All new shortened urls are stored here.(Only write)
2.Slave - All read operations are done from here if cache miss(Read only)
No of master & slaves decided based on the scale
1.ID Generator:
This is responsible for generating different ids.this components generates ids and stores them in available cache for faster retrieval.
This components pre-generates 50 ids and stores in that cache.When a id is requested it is returned and that id gets deleted from the cache.A new id is generated and stored in the Cache.
This components helps shortener micorservice by returning id in microseconds.
2.Shortener:
This microservice accepts the long url from the client.
This component retrieves one id from ID Generator,creates a short url using it.
The created url gets stored in cache.It is also written in master DB's
3.Redirect microservice:
This accepts all redirect requests from the client.
Check the cache for the url:
if hit ,it immediately redirects
if miss,it reads from the slave,updates the cache,then redirects