Detailed Component Design

We will now deep into these topics:

1) How to support 10k+ reads/sec i.e. High read throughput:

System is read heavy so it is essential to make system able to manage massive read scale.
This can be achieved via combination of caching layers, caching strategy and scaling read service horizontoally
Caching layers:
- CDN: We will use CDN for reads, so any read request will first closest CDN/edge location. If cache hit, the response is returned back, if cahce miss then the request is routed through API gateway eventually gets routed through read servers.
- Redis: Redis is second layer of caching implemented at read service.The flow is:
  1. If cache hit, return content immediately.
  2. If cache miss:
    1. Fetch metadata from the database.
    2. Retrieve content from object storage.
    3. Populate Redis cache.
    4. Return content.
- We will use Redis with an LRU eviction policy to keep frequently accessed pastes in memory. it gives us benefits like:
  - Reduces database load.
  - Reduces object storage reads.
  - Improves response latency.

- If Redis becomes unavailable, the Read Service can fall back to the database and object storage. This increases latency but keeps the system functional.

- Text updates rarely happens and to ensure freshness of data upon text deletion, we will invalidate cache whenever the Delete API is called or the background job that manages expire cache deletes data. This ensures data is correct always when read.
Scaling Horizontally:
- Additonally, we will horizontally scale our read servers and use our Load balancer to route traffic and distrubute traffic across these servers

2) How to handle duplicate paste creation request and ensure URL is unique and not easily guessable:

This is one of the most crucial part of the system. We need to ensure that all URL that are generated they are unique, and not easily guessable to avoid unauthorized access.
Approach we will take to solve this is:
- Generate random 7-10 characters base62 string that will be used as url code, so url would be like https://my-service/{url_code}
- However, using this there are chances for collision. So we need a mechanism to avoid these collision. The simple solution for these is the UrlCode column will have a UNIQUE constraint. If an insertion fails because of a uniqueness violation, the Write Service generates a new code and retries. This also ensures race condition does not end up creating duplicates
- But the chances of this are very rare, as if we use lets say 8 characters base62 then 62^8 ~ 218 trillion possibilities which is more than enough for our 1B unique text paste scale.
To handle duplicate paste creation, for eg:
- User requests a paste creation, syustem creates it but the response is lost due to network glitch, so user tries again, and hence we end up with duplicate paste records.
- Solution: idemptotency key.
  - So first request sends a idemptotency-key = key123, and all subsequent requests sends the same key in request payload.
  - System checks if this key is already processed
    - If processed, sends back the response. instead of creating a duplicate paste

3) How to handle Cache stampede:

To handle cache stampede,the caching strategies like LRU is somewhat helpful, but it fails when TTL expires and then suddently system recieved 10k requests.
To handle this, we can use reequest coalescing.
- So one request out of 10K request becomes a 'leader'.
- This requests goes to DB to fetch data.
- The rest all requests wait for the leader to fetch data from DB
- Once leader received data, the respoinse is shared with all other requests