Detailed component design

Caching

[Mid-level deep dive topic]

Performance and scalability of redirectURL() API is extremely important for this system. As such, we employ two levels of caching. Requests will naturally have locality of access, so caching will be effective.

At the closest location from the clients, we will have CDN storing short -> long mappings for the most frequently requested URLs. For example, if a celebrity posts a short URL link in their Social Network post, this mapping should be in CDN. CDN can be hosted at Internet Exchange Points (IXPs), making the response time from client quite short. It has limited storage space, so it should store a small set of the most frequently accessed mappings. High volume of requests are handled by CDN, without even reaching the API Gateway. It is quite beneficial from scalability & fault tolerance perspective.

In the data center, we will employ a caching node, e.g., Redis. As we can install multiple Redis nodes with 100s of GBs of memory, it can store larger set of mappings. It is still faster than accessing the database, so this would provide performance and scalability gain.

Both CDN and Redis Cache can employ Least Recently Used eviction algorithm to ensure currently popular mappings stay in cache.

Partitioning

[Mid-level deep dive topic]

Database and Cache should be partitioned for improved scalability.

Short URL is a good choice for a partitioning key because:

The services primarily look up cache & Database by short URL. By having this as the partitioning key, the services can find the right Cache & Database node to access quickly.
It is randomly generated, so it would be evenly distributed across nodes.

Other partitioning keys (long URL, user ID) would have disadvantages about these points.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10