Detailed component design

Performance and scalability of the Post service 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. The Post service is stateless and we may use a few instances of this service. Also, we may use the Kubernetes to scale this service efficiently and make it fault-tolerant, because it's a critical part of the system. Kubernetes cares about service availability, and it's health, by ping the configured service endpoint. The Post service uses the cache, we would use Redis to store most requested posts,we are going to use LRU to evict the stale posts. The Post service posts the posts to AWS Dynamo, it's a scalable and fault-tolerant key-value storage managed by AWS. The Post service reads the request from Kafka cluster. We would use Kafak partition replications to prevent losing data.

To search posts by tags faster, we would build an index in AWS Dynamo.

At the closest location from the clients, we will have CDN storing posts s. 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

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