Requirements

Functional Requirements:

• Upload & store text/code — a user can paste or write content and the system stores it.
• Generate a unique shareable URL — each paste gets a short, unique link (e.g., pastebin.com/abc123) the user can share.
• Retrieve paste by URL — anyone with the link can view the content.
• Expiration / TTL — pastes live for a set period (e.g., 24h, 1 week, or a custom time) then auto-delete.

Non-Functional Requirements:

• High availability — this is a link-sharing service; people open pastes hours or days later. If the site is down, those links are dead on arrival. Availability beats consistency here (worst case: someone sees a stale paste, not an error).
• Low read latency — Pastebin is heavily read-heavy (think 10:1 read-to-write ratio). The "open a link" path is the hottest path in the system, so reads should be fast and cheap. This will drive your caching strategy later.
• Scalability — assume millions of users. The system should grow horizontally as paste creation and traffic spike (e.g., Reddit Hug-of-Death on a popular paste).

Capacity Estimation

DAU - 5000000

Pastes per day - 1000000

Read to write ratio - 10:1

RPS(write) = 1000000 / 86400 = 12

RPS(read) = 120

Avg paste size = 10 KB

Storage per day = 1000000 * 10 = 10 GB/day

Storage over 5 year = 10 * 365 * 5 = 18 TB

Bandwidth = 120 * 10 KB = 1200

API Design

POST /pastes

{

"content": "...",

"expiration": "24h"

}

-> 201 Created

{

"key": "abc123",

"url": " https://pastebin.com/abc123",

"expire_at": "..."

}

GET /pastes/abc123

-> 200 Ok

{

"content": "...",

"created_at": "...",

}

-> 404 Not Found

{

"error": "Paste expired or does not exist"

}

High-Level Design

CDN - the client sends a request to the CDN to find cacheable content

Load Balancer - if the required content is not cached, the request is sent to a load balancer to distribute the load.

API Gateway - accepts incoming requests from clients and redirects them to the required microservices

Create Service - service for creating new pastes

Read Service - service for working with client-supplied links to Pastes

Key Generation Service - service for generating unique hash keys for new pastes.

Redis - used as a cache for pastes

PostgreSQL - pastes metadata storage database

S3 - storage directly for pastes content

Expire Cleanup Service - service that tracks expiration dates and removes expired pastes.

Database Design

PostgreSQL

• key varchar(8) PK
• content_path varchar "s3://pastes/{key}"
• category enum
• title string
• password_hash string
• created_at timestamp
• expires_at timestamp

S3

• s3://pastes/{key}

Detailed Component Design

Key generation service. A separate service pre-generates random keys into a table with used/unused partitions and hands them out in blocks of, say, 1000 to each app server. Keys become an O(1) lookup instead of a computation, collisions are impossible by construction, and keys stay unguessable. The standby replica handles the KGS single-point-of-failure concern; losing a block of in-memory keys on a server crash is acceptable since the space is huge.

Radis holds hot pastes — roughly 20% of daily read volume covers most traffic under a typical 80/20 access distribution. That's about 2 GB/day of hot content, easily fits in memory across a few Redis nodes with LRU eviction. Popular public pastes can also sit behind a CDN, since paste content is immutable once written.

Expire Cleanup Service - two complementary mechanisms:

• Lazy deletion: on read, check expires_at; if past, return 404 and enqueue for deletion. Cheap and correct from the user's view.
• Background sweeper: a job scans slowly and continuously for expired entries during off-peak hours, removes metadata rows, and deletes the corresponding blobs.