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:

• Low latency
• High availability
• HPA
• VPA
• Fault tolerance

API Design

I will design the API using a python or TypeScript (in case I choose Next.js as a framework). The API will feature these endpoints:

• /v1/url-shorten: A POST request that takes the long URL and transforms it into a short URL and saves it in a database. The table in the database can have this structure: (id,long_link,short_link,is_opened). The short link is indexed. This endpoint is featured in the shorten url service
• /v1/get-short-url: A GET request that returns the shortened URL from the database. This function is featured in the URL redirect service. When we call this endpoint, the associated function will query the database and return the long link to the user

High-Level Design

The system architecture is very simple. At first, we can consider this architecture:

A central server that runs the API. The server is responsible for taking the POST request (/v1/url-shorten) from a client andreturnings the shortened URL from the GET request (/v1/get-short-url)

If the system needs to scale, we can use this structure:

At first, the client app will send a request to an ingress controller to manage the secure access from the outside. Then a load balancer is necessary to distribute traffic across different instances of the shortening URL service and the redirect service. The system will also feature a Redis cache to efficiently return the shortened link when the user requests it from the URL redirect service.

A single instance of the database (example: MongoDB) to handle the reads and multiple replicas to handle the writes.

Also, the system features a monitoring & analytics service to monitor the latency and the cpu and memory usage.

Detailed Component Design

The client is a webapp based on Next.js with a TypeScript API. The database can be a PostgreSQL, a mongodb or supabase if we need to handle replicas more efficiently, or a simple Appwrite database. The appwrite database uses MariaDB as a backend and can handle Auth/OAuth and Tables. Also the appwrite database ensure that every link has a unique ID in the database. Once the link is opened the is_opened parameter is updated and set to true. A redis cache will store the most opened links in order to serve that efficiently.

If we need to monitor the latency, we can host the platform using Vercel and use the observability tools that are also available with the free plans. Otherwise, we can self-host the platform using a VPS and some open source monitoring tools such as cilium or tetragon or datadog/Dynatrace.

The observability pipeline will send the data using the OTLP protocol to a Grafana dashboard, where we can monitor the latency

In case we need to scale the system, we can use two microservices:

• a client to host the app frontend
• a server to host the backend logic, such as creating the short URL and handling the GET requests

Both of the microservices can scale horizontally or vertically. The system will scale vertically if mutiple user logs at the same time. The system can also scale horizontally if we need to manage multiple writes.