Detailed Component Design

clients could be of 2 types one who posts the long url in order to get the short url (POST call to Tiny Url Server). Before we generate a short url we would if the long url that has come for it any short url exists. Since it is a one to one mapping we can create index on long url column. And to quickly check if an entry exist we can use bloom filter if it return negative result. Then we will create a short url and store an entry of it in the database.
clients who hit the short url in order to get the long url (GET call to Tiny Url Server)
tiny url service creates a mapping (entry) in the db for long and short url mapping. And algorithm (hash function) which runs in order to generate short url from long url. Tiny url service also gets the long url based on short url.
Cache / Redis - all the request goes to cache first if its a hit that means key exists in cache and the data is fetch from cache and returned to client. In case of cache miss if its the very first hit it calls goes to the db creates and entry in cache and response is returned to the client. If the client subscription ended we will end 3XX status code (301 resource move permanently). In case of cache hit will serve the traffic with sub milliseconds latency since it is key value store. We can rate limit the request using token bucket strategy to handle burst of traffic with exponential backoff with jitter factor so that if n request hits at 1 sec get rate limited in the next retry they don't hit our server at the exact same time. For cache eviction we can use LRU strategy.
Database - SQL database to store the records (create and delete based on subscription) will store short url, long url, and timestamp
For Scalability -> we have multiple instance of tiny url running on different server (horizontal scaling based on CPU utilisation we will add/remove an instance) in order to increase the throughput.
Load Balancer -> to distribute the load across the instances. It can be used to direct the traffic to a healthy instance if the instance is down/crashed. Ensures healthy instances are always running.
Database replication -> we have one master database for write and one database for read. To make the data consistent we can CDC (tool like Debezium) which will use log file to replicate data in slave database (WAL). In case write DB is down we can promote slave db.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10