Requirements

Functional Requirements:

List the key functional requirements for the system (Ask the AI for hints if stuck)...

• The system needs to take a url and shorten it.
• The system should redirect to the origin url using the shortened one.
• The shortened url should be valid for a set period of time and then reclaimed so it can be reused.

Non-Functional Requirements:

List the key non-functional requirements (performance, scalability, reliability, etc.)...

• The system needs to be able to handle thousands of requests per second to generate shortened urls.
• The system needs to be fast in redirecting using the shortened url. Latency should be less than 100ms.
• The system should be highly available otherwise the links will not work. Aim for 99.99% availability. We need multiple servers so if there are any failures then users can still use the service.
• The links are accessed more often then they are generated therefore read speeds need to be fast.

Capacity Estimation

Estimate the scale of the system. Consider daily active users, read/write ratio, storage requirements, bandwidth, and any relevant QPS calculations...

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 need a post request to create the shortened urls. The user will post at minimum the following data

{

originalUrl: string

}

In the database we will store:

{

id: number,

createdAt: timestamp,

originalUrl: string,

shortenedUrl: string,

expiry: timestamp

expired: boolean

}

The post request will return to the user the shortened url.

Then we have a get request that will pass as a parameter the shortened url. Something like '/api/v1//tinyurls/{tinyurl}'. The service then returns a HTTP Redirect response.

We might need some rate limiting so you cannot send 1000s of requests and overwhelm the server.

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.

According to my design in excalidraw there is an API gateway sitting between the client and the system to handle request forwarding and rate limiting. The cache is first checked and if it exists then the response is returned quickly to the client. Otherwise there are multiple servers running to handle the thousands of requests and there is on database for all because one can handle the volume of data generated. And afterwards the cache gets updated as well.

For the post request it is much simpler, we do not check the cache and the request gets sent to an available server. Then generate the tiny url and persist it in the database.

There are a few options to generate the tiny url. we can use the unique id of the entry in the database to generate a base62 string and therefore there will never be any collisions.

Another option is to use a one way hash function and use the first 10 characters. Collisions here are possible so we have to query the database to confirm it does not already exist. And if it does already exist then append a counter to the original url string and try again until you confirm a unique url.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

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.