System requirements

Functional:

1. Generate a short url for a long url.
2. When given a long url and return a short url.
3. If we get a duplicate request to generate short url for a long url, we will just return the already generated short url.
4. User must be able to set expiry time on some of the urls.
5. We should provide customizable urls for some companies.
6. We should provide analytics metrics to view the metrics for each api.

Non-Functional:

1. The system should be highly available, we will choose availablilitty over consistency here.
2. Latency overheads should be minimal.
3. We should be having our servers as close to clienrt as we can i.e in every region we must be having our servers.

Capacity estimation

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

1. tps: 100 read tps and 1 write tps.
2. memory estimation: lets asume 300Bytes for one entry, so around 3 GB of data will be generated everyday.

API design

Define what APIs are expected from the system...

only two apis for now

1. getShortUrl(String longUrl, Optional expiry_time, optional customized_prefix_url): generates the short url and returns it.
2. getLongUrl(String shortUrl): gets us the long url with a 302(temporary) and increase its count for the backend, returns an error if the short url is not found.

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

we are going to use nosql database for this, as our main goal is availability over consistency, also we dont require the complex quries so sql has no major advantage here.

schema:

{

uniqueId: string, (primary key)

shortUrl: string,

longUrl: string,

ttl: timestamp

}

High-level design

the client request first goes to the dns, then it goes to the load balancer, it then goes to the server, which maintains a cache, and a database as the source of truth.

Request flows

For the write flow: for the write we will use write around cache strategy, firstly the request goes to the web server to generate the short url, the server will generate the short url and then puts into the db.

For read flow: we will use read through strategy, the web will ask for the long url, the request will go to the cache, it will check in the cache, if not found, it will check in the db and then populate the cache and return the response.

Detailed component design

Webserver: the webserver will have just two api to support,

we can use any standard web server, and can later scale it as per the load, also the webserver uses the cache only in read, the writes are made directly to the db.

Cache: we will use write aside for the writes and we will use read through for the reads, we will set 15 minutes as the cache expiry limit. Also we will use LFU cache eviction policy.

Trade offs/Tech choices

1. With write aside we are allowing stale data to be present in the cache. so there will be scenarios where we are serving stale data, so we are tradingoff data correctness for faster replies i.e reduced latency.

Failure scenarios/bottlenecks

1. cache size can be a botttle neck but we can easily scale it up horizontally.
2. The system can be overwhelmed in case of a hotkey event.

Future improvements

1. have different cache pools for populer keys,
2. we can also implement security measurements like preventing from users to make unnecessary calls with help of rate limiters.