Loading...
Read to write ratio:
10:1 -> heavy on reads
External Endpoints:
SQL because we want strict relationship between shortened and long URL
Shortened URL Table:
URL clicks table:
SQL because we want strict relationship between shortened and long URL
Shard database -> shard by ID
Create replicas to reduce reads on a single DB
For hashing the URL we can use MD5
GET:
Client clicks on shortened URL
Update number of clicks table
Grab the original URL from DB
Send original URL to client-side and client-side reroutes to URL
POST:
Client puts in URL
We check DB if orignal URL exists
All requests go through API gateway, where it is rate limited
and then goes through load balancer to distribute throughout servers
Round robin should be fine for how load balancer distributes requests
We can use redis cache for most used URLs:
Can run CRON job hourly to update cache, since we have table to count number of visits, we can use that table to update the cache
Using MySQL and a DB to store all the shortened URLs can expensive to scale
We can use redis and just store the 200000 most used URLs in redis but generating existing URLs would take longer
Bottle neck could include too many reads on a single DB, we deal with this by using replicas
Bottle neck could be too many writes on a single DB and DB running out of memory, we shard the DB to prevent this
Depending on what users want, we can update or add features