Loading...
200,000 DAU
Say 20% of the user write to the db per day thats 40K write and 4 Million read. Say in the next 5 years we have an increment of 50%. Meaning our DAU would increase to 300K DAU.
For the storage say each row is 500B, if we have 20% (that is 40k) write per day that means we will be needing around 20MB of data daily. For 5 years daily data stored would be 3.0MB per day
POST /url - Create shortUrl
Request: {"longUrl", ""}
Response: {"shortUrl"}
GET /url/{shortCode} - Redirect to the long URL with status 302
Load Balancer
API gateway
API Service (Redirect, Creation, ShortCode Management Service)
Redis
Database (MongoDB)
Load Balancer: This will be used to distribute request from clients to difference service instances.
API Gateway: This will be used for authenticating user, rate limiting and to route request to either creation or redirect service.
Redis: Cache for fast (low latency) response, uniqeness and session management
Creation Service: This service handles creation of url. When called it first check the cache (redis) to see if the long url already exist, if it does, it returns the shortcode to user. If not it calles ShortCode Management Service (SMS) for short code, the SMS marked the given code as used and creation service store this code alongside the long url to db (mongodb)
Redirect Service: This check the redis if the short code exist, if yes redirect the user. If not query the db for long url and redirect the user to this long url.
ShortCode Management Service: This service manages shortcode by pre-generating shortcodes and marking them if assigned to a long url.
Database : Mongodb was used because of it distributed ability and faster query.
NB: Retry (exponential) mechanics would be used incase of failure and circuit breaker would be used in case of persistent failure
Entities url:
UUID - Primary Key
longUrl - Long Url VARCHAR(255)
shortCode - Varchar(10)
createdAt - Timestamp
updatedAt - Timestamp
Indexing ShortCode.
Since it read intensive. Multiple replica will be created. Also sharding will be done to reduce the amount of read done on the db. Connection pool will be created to manage the connections.
shortcode would be use as the shard key and eventual consistency would be used since we are focusing on high availabilty
Redis: We need high read, constantly reading data from DB would cause to much work on the db and it slows down respons. so instead of constantly reading we reduce that by using redis.
Database: Also, since the write amount is high, sharding will help distribute the write request to multiple db this increase write since multiple db can be writen to in parallel. Read replica helps in availabilty and fast read