System requirements

Functional:

List functional requirements for the system (Ask the chat bot for hints if stuck.)...

1. Creating short url
2. Redirects from short url-s to "real url-s"
3. Checking original url before creating short url
4. Logging metrics for count of using short url-s
5. Creating and using redirects only for authenticated users

Non-Functional:

List non-functional requirements for the system...

1. DAU - 100 000
2. MAU - 3 000 000
3. Created links in month per user - 5 links
4. All created linkgs in month - 15 000 000
5. Avg RPS for creating - 6
6. Avg RPS for go for short url - 20 rps ( 17 redirects from one user per month )
7. SLA - 99.8 ( downtime less than 1h 26 min in month )
8. P99 latency for short url - less than 800 ms
9. Store short links for 5 years

Capacity estimation

Estimate the scale of the system you are going to design...

API design

Define what APIs are expected from the system...

### Creating short link

POST {domain}/api/v1/shorten

{

"original_link": ""

}

response:

{

"shorten_link": ""

}

### Get data by shorten link

GET {domain}/api/v1/redirect?shorten_link=value

{

"shorten_link": ""

}

response:

{

"original_link": "value"

}

Database design

Defining the system data model early on will clarify how data will flow among different components of the system. Also you could draw an ER diagram using the diagramming tool to enhance your design...

Using key-value sharded noSQL database for storing relation shorted link<-> original link.

Key is MD5 hash for shorten url.

Value is original url. Also adds created_at for checking TTL for 5 years using some async process.

High-level design

You should identify enough components that are needed to solve the actual problem from end to end. Also remember to draw a block diagram using the diagramming tool to augment your design. If you are unfamiliar with the tool, you can simply describe your design to the chat bot and ask it to generate a starter diagram for you to modify...

Short links generates using UUID_v7 mapping.

When generates UUID_V7 value ist encodes as base62 and stores to cache and database.

Collisions are impossible due to UUID_V7 structure.

For distributing data by shards we also adds "shard key" in front of UUID_V7 value

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Get orignal link flow:

1. Client requests GET api method providing short link in query param
2. Service recieves short link
3. Service try to get original link in cache
4. Service doesnt find original link in cache
5. Service go to Sharded noSQL database and hashes short link from request body and try SELECT data
6. Service finds original link and send it in response body to client with 302 http status code

Create short link flow:

1. Client provides original link in query param POST api method
2. Service recieves original link and tries to validate it ( makes http request )
   1. If original link doesnft valid service returns 400 to client and error description
3. Service generates short link. Using async queue with creating "shortin job" and responses user immediately with 202 accepted response
4. Serives saves created short link value as short link

Detailed component design

Dig deeper into 2-3 components and explain in detail how they work. For example, how well does each component scale? Any relevant algorithm or data structure you like to use for a component? Also you could draw a diagram using the diagramming tool to enhance your design...

short link - uuid_v7 encoded as base62.

Also adding one symbol in front of value - symbol using for checking for what shard making query.

Logic for whar shard make query is implemented in load balancer - service back end and databases are deployed in same data center. If symbol is for shard 3 - then request goes for third datacenter.

For not resharding when we will increase shards space we will create a lot of shards from the beginning.

Data will destribute for shards using round robin.

Generating short links uses Kafka as Async task manager - we get task from user in responses to him with 202 accepted. While we generates short link.

Cache is distributed redis

Trade offs/Tech choices

Explain any trade offs you have made and why you made certain tech choices...

Failure scenarios/bottlenecks

Try to discuss as many failure scenarios/bottlenecks as possible.

load balancer also implenets rate limitiing for avoiding downtime thanks to ddos requests from client.

Our service deployed in several datacenters ( 4 ). Database is replicated using RF = 3 for different data centers.

Redis using for storing cache data also replicated.

Future improvements

What are some future improvements you would make? How would you mitigate the failure scenario(s) you described above?