Detailed Component Design

Services

URL Shortener Service
1. This service will handle the load for the shortening of the URL.In this service we will be taking the long URL and giving a new uniquely generated short URL. We will make sure we generate the URL and then save it in database as well.Each long url must have an attached short code which will help us identify the long URL
Redirect Service :
1. We will have a simple service that will be directing the short URL to it's actual URL.In this service we will be getting the short URL as the payload and make sure that we map the short url to the actual long URL and return 302 or 304.
2. We will be fetching the short code as a parameter from the URL (under a hood a simple GET /<short-code> API)

We know one thing for sure that the URL Shortening Service is going to be a write heavy service and Redirect service is going to be read heavy. We already know that we have 100:1 read to write ratio so we need to now handle the large reads in the URL shortening service and reduce latency in the response time.

Database Design

Let's design a simple schema for storing the data inside the DB. The schema design is as follows

shortCode (Primary Index) : string,

customAlias : string,

createdAt : Date

longUrl : string

This is a simple schema for the URL generator. shortCode is primary index because this is the key we will use for searching in our DB. Since our DB is read heavy we need to reduce search time complexity from O(N) to O(logN) which is good for faster searches.

Indexing will be enabled on the DB to make our search faster.

What should be the DB?

A simple PostgreSQL or other non relational db we need to do manual tuning for sharding indexing and replication.

So the best thing that we can do is use DynamoDB or MongoDB because it has these configs handled automatically.

To make our system highly available we need to make sure that we have a primary database (master) where all the writes will happen and multiple replicas (slaves) where the read will happen.If tomorrow we have a DB down we can have an election and choose a new leader having the most latest data (an asynchronous replication would help here).

To make sure that our DB can handle multiple request under load and stress we need to make sure we just break the DB into smaller chunks as we say sharding so that we can scale our DB when load and stress increases. This makes sure under load our DB performs well and doesnt go down

But how it happens?

Submissions

Displaying Solutions with Scores Ranging from 1 to 10