Designing A Simple Url Shortening Service A TinyURL Approach - System Design

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:

The service has to scale on demand
the data base connections has to be preserved
100 ms of Latency
It has to follow the OWASP Top 10 items
The Id will have 7 digits of AlphaNumeric using Snowflake pattern and converted to Base62

API Design

For this api will be need two paths in the same domain,

POST shortener/url/

Response Status Code: 201

GET shortener/url/{Id}

Response Status Code: 301

High-Level Design

The Client will fill up the form with the url that has to be shortened and will submit It.

Before the api there is a layer of ensurance and DNS management.

On the Server-side there is a gateway will evalute de token sent by front end calling the OAuth server.

The url shortener service is an Fargate published in a LoadBalance.

The IdManager service is an Fargate published in a LoadBalance will store da Ids in a DynamoDb Table.

The main DataBase will be for the URLs dictionary and other Data will be a DybamoDb.

For Read Access the most accessed url is stored in a redis cache.

As this will became a worldwide domain, to keep a low latency for everyone and avoid to turn the service a bottleneck to the flow, It will have a CDN that will cache the response for the edges of each region through the world.

The gateway will have a cache too.

Detailed Component Design

The services are using .NET and and following the Clean Architecture, creating a possible expansion of It. The integration with other services will be made using Circuit and retry policy.

Every data inserted into the database will be available on cache for 5 minutes, after that time only the most accessed url will be there for a long term following some internal rules.

The Id Manager is a Fargate, but for cost optimization It can also be an Lambda built using .NET and AOT.

It will manage some ranges of Id, in order to avoid racing conditions, and will use the DynamoDb to manage when create the Id for each range.

Before each server get an Id, It will register Itself calling the GetId and sending some metadata about the running task, like Id, IP and name. Server A gets IDs 1–1000, Server B gets 1001–2000.