Requirements

Functional Requirements:

1. Store text and generate a unique shareable URL.
2. Retrieve by lookup
3. Expiration/TTL
4. Paste Owner can delete before expiration.

Non-Functional Requirements:

High availablility - Pastes should always be readable.

Low read latency - Very high read compared to write.

Capacity Estimation

Read/sec - 200

Write/min - 100

API Design

Define the APIs expected from the system. This is your chance to analyze and define the read and write paths so that you can come up with the high-level design...

POST /pastebin/paste

returns URL and TTL

GET /pastebin/url={url}

DELETE /pastebin/url={url}

High-Level Design

Describe the overall system architecture. Identify the main components needed to solve the problem end-to-end. Use the diagramming tool to create a block diagram.

Database Design

Define the data model. Identify the main entities, their attributes, and relationships. Consider the choice of database type (SQL vs NoSQL) and justify your decision based on access patterns...

Detailed Component Design

POST /pastebin/paste

returns URL and TTL

1. URL is generated and randomized to make it harder to guess.
2. TTL is assigned to the URL.
3. This information is stored in Postgresql and the content of the text is stored in AWS S3 whose url(reference) is stored in the Database.

GET /pastebin/url={url}

1. The generated url is passed as parameter and it is routed 302 to the public url
2. Cache hit-> When Redis cache is a hit, it returns the content.
3. Cache miss -> fetches from S3 and populate Redis.
4. This returns the public url (AWS S3) if TTL is not expired.

DELETE /pastebin/url={url}

1. When this API is triggered, the TTL is updated in the DB and Redis Cache is updated accordingly.

CleanUp Service monitors TTL and clean up the Redis Cache accordingly.

If two text hits the api at the same time, we will use hash(content+timestamp) to randomize the key.

If clients POST times out, then we use the content hash and ensure that no duplicates are created.