Loading...
To create short urls aliases for user provided urls
Low latency for redirects
High availability for redirects
200 write rps
20000 redirect rps
100 bytes of long url
+ 8 bytes of short url + buffer for other fields ~= 256 bytes per url_mapping
5x10^6 bytes per second
3600 * 24 * 365 = 31 ~10^6 seconds in a year
Which translates as redirect operations need multiple servers but the write operations could be served with a simple server
shortenUrl
input: user_id, long_url
output: short_url
redirect
input: short_url
output: redirects to long_url
Url_Mappings
short_url, primary key (8bytes)
long_url (100 bytes)
user_id
... other fields
Users table (secondary)
CDN for redirects
Api Gateway for security
Load balancer for horizontal scaling
Separate Redirect and create url service for appropriate scaling
Datacenter In-memory Redis cache
key-value NoSQL database
Write Request
create url service receives the request
writes it to the database
Read Request
When a request first arrives it goes through
CDN -> Service -> Redis cache -> Database
The CDN and redis cache are pull through caches
The CDNs and the the datacenter cache use LFU eviction policy, keeping the most frequent data near users, and delegating less used data to the datacenter cache. They also use read through caching
For the datacenter cache we will choose Redis, for its replication and availability features rather than simpler options for our simpler case.
The services use lightweight servers with event driven frameworks, to scale horizontally efficiently and use an API gateway and load balancers to keep scale.
As their only function is very specific and the load is very different scaling of each sevice is decoupled. The event driven server optimizes usage for I/O operations.
The database will be dynamo db so it can scale with demand while providing simplicity and availability with good consistency.
Our database choice of Dynamo DB exchanges cost for scale and demand. We also sacrifice the query capabilities for relations which while unused could be useful for additional features
The choice of using a CDN and Redis caching introduces extra complexity and cost while improving read performance, scalability and reducing read latency.
If volume follows even distributions caching the most frequently used could generate many cache misses, defeating their purpose.
Analytics might be harder to implement due to the reliance on the CDN for redirects, in which case owning the CDN, or extracting analytics from their service would be more difficult than owning geographically distributed servers
Dynamo DB is very limited in query
capabilities so no complex features could be easily supported by this system.