System requirements

Functional:

• generate a short url when a user submits a normal url

Non-Functional:

• performance
• scalability
• availability
• reliability
• security
• data privacy
• monitoring and logging
• maintainability

Capacity estimation

1000 TPS (200 write, 800 redirect)

assume each row consists of

original url, and hash, estimated 1kb

database increase 200 * 3600 * 24 * 30 * 1kb = 500gb / month

API design

1. getShortUrl(originalUrl) -> shortUrl (restful)
2. http get, getOriginalUrl(shortUrl) -> http redirect to originalUrl

Database design

originalUrl: string/text

hash: string/text

High-level design

1. static webpage, https://short-url
2. dynamic webpage, https://short-url/hash

Request flows

For submitting url:

web browser http post the normal url -> api gateway -> shorter service generate a hash and saves the url

For redirecting:

web browser http get -> api gateway -> shorter service

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...

Trade offs/Tech choices

1. We chose NoSQL for availability and scalability. SQL can be more robust but harder to scale. Our data model doesn't have many relations.
2. We chose to add api-gateway for easier authentication and monitoring, but it will cost money and add a little complexiility.

Failure scenarios/bottlenecks

1. when database cannot be written, url shortening will not work, but redirect will work
2. when database cannot be read, redirect will work but shortening will not
3. when the api-getway fail, both function will fail
4. when the shorter service fail, both function will fail

Future improvements

• rate limit
• auto postpone expiry date when a shortUrl is used