Loading...
the system should create a short url and securely redirect users. the system should allow users to quickly and easily create new redirects, understand the state of their current redirects and cancel redirects. server uptime is critical and should remain up without downtime >99.9% of the time.
low latency response time - 50ms or less to redirect a short url to its corresponding long url
scalable architecture - the system shall be designed in such a way that should it receive more traffic than initially anticipated, additional instances could be added seamlessly to handle traffic
robust logging system - tracking of volume, timestamp, response time, incoming requests, user bounces, error messages and account actions
This system will be able to handle 10,000 concurrent users at a time with the availability to be scaled in the future. Any collisions in the short urls can be handled by picking a sufficient length for the urls
This system will expose custom urls in the format oururl.com/uuid. GET requests to this url will lookup from our database the corresponding long url and redirect the user. we will also expose oururl.com/api which will handle all requests relating to account management such as creating new url mappings, modifying existing ones or deleting them all together. this will expose GET, POST and MUTATE methods to handle such updates. we can identify users by having them send a bearer token from the authentication provider and cross referencing it with a server side authentication provider call. while slow, this only occurs during the initial creation of the url.
The database for this service should be pretty simple.Tables:
enhancements could include organizations which allow multiple users to handle the same set of mappings. to increase speed of shortURL lookup, we can use the short url as the primary key for the mappings table
See block diagram
The sequence diagram is set up like an expected redirect service flow
The server and the database are the two most necessary components to scale.
The server should have a load balancer which routes traffic to the various server instances. We will also need to implement a message queue to ensure all requests are handled and not dropped. We can take advantage of threading or rabbitMQ to handle several requests at once but if our service finds itself being overrun we should dynamically scale up in instances. The startup of additional instances will have a delay so we should ensure that the system has sufficient time.
The database tables should be optimized for quick lookup of the short to long urls. We can also do things like cache long (or popular) url mappings on the server side to prevent the need to perform a lookup on each website visit.
One tradeoff of spinning up more instances is this will incur higher cost.
One extraneous condition that this service could face is a DDOS attack
our requests could be routed through a service such as cloud flare who provides protection. we could also rate limit users and ips to prevent abuse
additionally, handling user's custom urls could add additional complications to the system