Detailed Component Design

Load Balancer: We will place a network load balancer so as to filter the packets at layer 4 level and protect our system from network attacks such as TCP sync attack or UDP overflow.
API Gateway will handle auth, rate limiting and cache responses as required. Rate limiting will be using the tocken Bucket algorithm with 60 requests/ sec per user. If the reate of requests exceed, 429 will be returned to the user from the api gateway itself. The allowed rate can be increased for subscribed and premium users.
CDN: To improve P95 and P99 latency, we can cache the results in CDN, thus ensuring ultra low latency at edge locations.
Cache: Redis is used as a cache to store the unique keys and primary key mapping of pasteBin DB. It also has the mapping of chunkId and respective mapping of the S3 url where the chunk is stored, with a TTL of 10min. Follows LRU Cache eviction policy. Write through policy followed for writing in cache, and Cache aside policy followed for reads.
PasteBin Service: Handles the fetching of presigned s3 urls for each chunk for multi part upload, and DB look up for metadata of each chunk. This can be made highly available by having more than one instance in more than one availability Zone using Auto scaling groups.
Key generation Service: Generates a unique key for each upload, there by storing the mapping of one key to the primary key of the PasteBin DB.Computes the hash of the incoming primary key and the timestamp to generate the hash, thereby avoiding collisions. the first 20 characters are used for the unique key, there by having a total of 20 raised to 20 combinations.
S3 is used for object store as the file size of upload might be in MB or GB, thus cannot be stored in DB. Lifecycle policies can be used to optimize cost. A server less architecture comprising of S3, event bridge, SQS and lambda combination can be used to populate the metadata in the PasteBin DB asynchronously.

Tradeoffs:

Single point of failure: Load Balancer can act as a single point of failure, thus we need to make it highly available by having 3 backups in multiple availability zones and regions, thus making disaster recovery possible.
Concurrent writes: When two users are actively editing the doc, then all the edits should be saved in a buffer, and then after a timeout, the updates should be sent in batches, in order to minimise network calls.
Eventual Consistency: Since the sytem is highly available, if another user immediately opens the generated link, then the recent edits might take time to show (4 to 5s). This can be improved by making our system write optimised and using DB such as Cassandra where Leaderless principle is used, as opposed to MongoDB (which uses Master-Slave)
Cache TTL: The stale data might be visible in cache for TTL of 10min, thus cache should be updated everytime there are new edits.

Additions:

We can run a schedular job ,where a worker queries the DB every 15min to check the content which has reached its expiration, and can delete such content from the DB, thus making some space free. This can be server less as well.
We can use a message queue like Kafka between the PasteBin service and Key generator service inroder to decouple the application, by making them publishers and consumers of respective topics, thus making scalability easier.
Another advantage of adding Kafka is that, even though the DB goes down temporarily, Kafka will have the data retained for 1 week, thus giving us ample time to run the script to populate the DB async.
To prevent Cache stampede, we can pre fill the cache with the most common/ required data from the DB on boot up/ when the cache node restarts.
In order to deal with hot Keys, the cache can be distributed into a cluster, where each cache will have the details about the hot key.
Celebrity problem: When a particular user has a very popular upload, where many reads are occurring, the content can be cached in CDN itself, thereby reducing the load to DB and cache.
Problematic IPs and hazardous IPs can be blacklisted by adding a WAF in front of the Load Balancer to prevent network attacks from bots/ malicious users.
Regex pattern matching can be implemented in api gateway to prevent XSS and SQL injection attacks.
POST api should be idempotent in nature, in order to prevent duplicate entries in DB and S3, thus saving cost.
On API failure in internal services, there should be a maximum of 3 retries. Since message queues are used in between services, retries are possible since request/ job wont be deleted from the queue. Upon successful processing of the request/ job, it can be removed from the queue.
On network failures of DB/ Cache/ Internal micro services, circuit breaker pattern should be used in the micro services in order to reduce the number of network calls. Timeout should be set to 1 min, where a scout is sent every 1min to check the network health of the target.
For generating a unique key, there might be an edge case where 2 keys would be same, for this, a distributed counter shuld be appended to the hashed value and rehashed using a salt value.
Read replicas should be created for databases. The PasteBin DB can be and RDBMS / Sql DB like postgres for storing metadata of the uplaods that includes chunkId, expiration_timestamp, id (PK) and S3 url. Key Generator DB can be a key value store like dynamo DB for high availability and scalablity.
Sharding strategies for RDBMS table: the Db should be shared based on the Id of the row. Consistent hashing should be used for sharding, so that only the affected rows withing the updated row is reconfigured, there by reducing the number of re arrangements.Partitioning based on mod of id should be implemented within the same shard.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10