Requirements

Functional Requirements:

• Create a short URL for a given long URL.
• Return the long URL associated with a given short URL.

Non-Functional Requirements:

• List the key non-functional requirements (eg low latency, scalability, reliability, etc.)...
• horizontal scalability
• reliability
• low latency
• high availability
• low redirect latency

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

We will have /createShortURL, which will be the main api that takes the given url as payload and checks if it already exists in the cache if it does takes the value and returns it other wise it creates a new entry in the database and adds the new entry into the cache as well. The response will be 200 if sucess. 4xx if something unexpected happens and 5xx if the error is from the application side. We will have /getFromCache which will help us get data from cache. It will take the url given by the user in /createShortURL. We will have /getFromDB which will take the payload from /createShortURL. Both of these will give 200 for successful request, 4xx if something unexpected happens and 5xx if the error is from the application side. Then we have /invalidateCache which invalidates the cache. This give 202 saying the invalidation has begin. /health for health check of the application 200 for healthy application.

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

So we will have a frontend hosted on a cdn which will make it fast and from there it will talk to backend through the load balancer to the cluster of servers which can scale depending on the load. When a request to create a short url comes the server first checks the cache to see if it exists there if yes then it returns the shorturl already present otherwise it will make a new entry to the DB and then adds the new entry in the cache as well making it. TTL will be 2hr after which the cache will be invalidated. This is to make sure nothing stale is present in the cache.

Detailed Component Design

Deep dive into 2-3 key components. Explain how they work, how they scale, discuss tradeoffs, capacity, and any relevant algorithms or data structures.

As mentioned in the high level design we will be using cdn for frontend making it very efficient. We will be using auto scaling for the backend so that it can scale depending on the load. Since this is horizontal scaling we would need a load balancer which would balance the load. Im thinking of distributing the load based on the amount of load a server has on it. This strategy avoids overloading one server with getting the hits. For cache we will use redis to store the shortened url and the original url as key value pairs. Coming to the shorting logic we can maybe use a format such as first 5 letters from the original url domain and add a 4 digit random base64 code making it somewhat readable and random since base64 can be generated randomly.