System requirements

Functional:

A: Create short alias URL from original URL

B: reroute short alias URL to original URL

Non-Functional:

latency:

we need B requirement (reroute) to be at most 10 ms

A can be slower, maybe 1 second

scalability:

300,000 creates a day

1,500,000 reroutes a day

availability:

reads are the most important

consistency:

eventual consistency is good enough

Capacity estimation

4200 bytes * 300,000 per day = 1,240 mb

50 terabytes for 10 years

API design

createAlias(url: string, user_id: string (uuid), experation_time: string? = None)

• creates the alias, saves data to db

reroute(alias)

• fetches db data, reroutes

Database design

we will use a No-SQL because it's more performant, the performance-sensitive data is not relational

alias:

id: 8 byte string PK

URL: 2048 character string - up to 4096 bytes SK

created_at: 16 byte string

user_id: 16 byte uuid string

user:

id: 16 bytes uuid PK

created_at: uuid

High-level design

we have an api gateway to route the clients request (reroute or createAlias)

posting the alias:

• in order to handle many alias posts we have a job queue that will allow many writes with retrying if fails.
• the job queue on success will update database and also the cache

getting the alias

• the client gets the long url using the alias
• we have a a cache to save db read time, it could also be a cdn to make the read even more performant.

Request flows

client can

• create alias which will create the db data
• reroute which will call cdn

Detailed component design

the "post alias" will create the alias, we will use a random id to create the alias, or if the user submits one it can be used as well.

Trade offs/Tech choices

generating the alias ->

• we can use random alias or hashed,
  • hashed would be more complex because it's possible for more than one url to turn into a new hash. we need a way to take care of this.
  • random is easier.

Failure scenarios/bottlenecks

if the api gateways is a single source of failure

job queue has added complexity

cache has added complexity

Future improvements

if we expand user functionality then we might favor a relational database (SQL) for their information.