Detailed Component Design

For the URL generation, we need to encode the long URL in a separate format. I propose that we use some sort of encoding like base64 encoding. Next, we will need some way to avoid collisions. I propose that we can associate each long URL with an integer ID that continues to increment. Therefore, when we encode a new URL, we have high confidence that we haven't returned a duplicate shortened URL. Finally we can store our generated URLs in a database that we can check if we've generated it before. If we have, we can append some random character to the URL.

For the data storage layer, we will use a noSQL database. This is because noSQL has a high guarantee on availability because scaling is much easier. This comes at a cost of consistency, but eventual consistency is likely acceptable for our use case.

For the caching layer, we will utilize redis keyed on the passed in URL. We will use a pull strategy that will allow us to efficiently serve hot URLs when they are being generated or read. When we have a cache miss or the entry expires, we will read data from the API gateway and write it back into the cache.

When we have "hot" traffic patterns, we will use a load balancer and CDN to distribute the traffic to the appropriate API gateways.

For database sharding, we can use a hash of the shortened URL as the partition key to guarantee that the resolution service always reads from the same shards.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10