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 ensures that every link has a unique hashed 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 them efficiently. In case the shortened URL service fails, the loadbalancer will send the traffic to a replicaset of the service if the shortened URL service exceeds the load by 2x the average. I'll also set a cache TTL of 24h to ensure that the system will serve the most viewed links efficiently with an allkeys-lfu policy (last frequently used). Once a link is deleted i'll also remove the link from the cache.

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.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10