Loading...
User can send full url and get short link.
Generated links will stay available for 30 days unless the user decided otherwise in the form.
No login. Users won't be able to create a list of owned short links
Links should be removed if not used for 365days
Short links will be unique and randomly generated.
Availability is more important here than consistency - that won't be any problem if user won't be able to use a link for awhile until database instances synchronize.
The is no need to think of throughput vs latency - path is simple.
there should be rate limiter to prevent DOS / DDOS
Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...
POST /generate
{
"url": "....",
"lifetime": "30"
}
server receives info for how long keep freshly generated short link for provided url
GET /short/[random-characters]
that's how links will look like when generated
server should respond with redirection after receiving request on this endpoint
No matter if client is asking for new short link or for redirection base on already existing - rate limiter is the first thing to face
then request is passed to server
in case of redirecting request - database simply gives back what's under provided link and server can respond with redirection
update last_used
in case of creating new short link
server should create a hash value base on provided URL + salt (possible to increment)
next - server tries to save created entity to DB
DB should ensure uniqueness of hash (unique constrain on column)
if save operation went well - response is given back to user
if saving entity went wrong due to hash being not unique - repeat whole operation with incremented salt
Scheduler should be ran each day to remove expired links
Entity:
Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.