System requirements

Functional:

• generate a unique short url which be used to redirect towards the original url
• redirect to the original url when accessing the short url
• enable custom URL generation for users
• offer aggregated analytics based on usage

Non-Functional:

• handle up to 1k RPS
• low-latency
• easy to scale

Capacity estimation

For capacity estimation we'll be using the typical patterns of such a service and assume that the service will have 1k users at launch with a growth rate of 10% and assess the number for the 6 month mark after launch.

Analyzing growth scenarios for DAU and RPS:

1) Baseline scenario is with 1k DAU. Considering 50 requests per DAU this would result into 50k requests per day.

2) Moderate growth scenario with 10% growth would result in 6 months with a 1k * 1.1^6 = 1.7k DAU. Assuming 50 requests per DAU this translates to 85k requests per day.

3) Aggressive growth scenario with 20% growth would result in 6 months with 1k * 1.2^6 = 3.2k DAU. Assuming 100 requests per day this would mean 320k requests per day, which is equivalent to almost 4RPS.

4) Peak usage scenario should cover 10K DAU. Let's assume 100 requests done per each DAU which would result in 1M requests per day, which translated to 13RPS

API design

create tiny url - POST /api/url

read tiny url and redirect to canonical url - GET /api/url/

update tiny url - PUT and PATCH /api/url/

get analytics data for a url - GET /api/url//analytics

Database design

url database db schema:

• tinyUrl - primary key containing the unique hash id
• canonicalUrl - text
• timestamp
• user_id - foreign key
• status

registered users db schema:

• primary id - unique id
• timestamp
• email
• name

with unique index on email

expiration db schema

• tinyUrl - unique foreign key
• expiration_time - timestamp field

with index on expiration_time

analytics db schema:

• entry id - primary key autoincrement
• tinyURL id - foreign key
• user_id - foreign key
• accessed_at
• user_ip
• user_agent
• location

High-level design

Considering our capacity estimation we can choose a simpler approach consisting of:

• api gateway (nginx or AWS API Gateway which will also handle load balancing)
• web-server
• cache
• database

The API Gateway will handle authorization and authentication, as it will be integrated into an authentication server.

The webserver handles both reads and writes.

For writing

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

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

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.

Future improvements

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