pastebin

A developer pastes 50 lines of error logs and clicks "Create." Within 200ms they have a URL to share. Let's build this write path step by step.

The First Decision: Where Should We Store the Text?

The simplest approach stores everything in one database table:

CREATE TABLE pastes (
  id VARCHAR(8) PRIMARY KEY,
  content TEXT,
  created_at TIMESTAMP
);

At first glance this works. But consider what happens at scale: paste content varies from 10 bytes to 1 MB. With 1M pastes per day at 10 KB average, we accumulate 900 GB of content over 3 months. Storing all of that in a relational database creates compounding problems:

• Table bloat — Large TEXT columns fragment across storage pages, slowing unrelated queries on the same table
• Backup pain — Database dumps include all content; 900 GB takes hours to export and restore
• Cost — Database storage costs 5–10× more per GB than object storage ($0.115/GB vs$0.023/GB on AWS)
• Serving — Relational databases aren't designed to serve static blobs at high throughput; CDNs can't pull directly from PostgreSQL

This points toward separating metadata from content: database for structured metadata (fast queries, indexes), object storage for bulk text content (cheap, durable, CDN-compatible).

The Write Path

When a user creates a paste, the system executes these steps:

1. Request arrives at the load balancer and routes to an application server
2. Validate — Check content size (reject > 1 MB), parse expiry duration
3. Generate ID — Create a unique 8-character alphanumeric identifier
4. Store content — Write the text to object storage at path /{id}
5. Save metadata — INSERT INTO pastes (id, created_at, expires_at, size_bytes)
6. Return response — The short URL and delete token

The object storage write adds ~50ms of latency. This is acceptable for a write operation — users don't expect sub-10ms response when uploading content.

The Second Decision: How Do We Generate Unique IDs?

The short ID like a7x3k must be unique across all 90M pastes in the retention window, and — critically — must be unpredictable to prevent enumeration attacks.

Our Choice: Random Generation

Random 8-character base62 strings with collision detection via the database primary key constraint. The collision check is "free" — it's just the INSERT itself. No separate lookup query needed. The implementation is simple, the security properties are strong, and the collision probability is negligible at our scale.

Data Schema

The schema is intentionally minimal — 5 columns, small fixed-size rows. The actual text content lives in object storage at path /{id}, matching the URL structure. This keeps the database fast, backups quick (~9 GB), and queries efficient.

A teammate clicks pb.example/a7x3k in a GitHub issue and expects the page to load instantly. With 1,200 reads/sec (6K peak), we need a read path that scales without scaling the origin infrastructure proportionally.

The Baseline: Read Without Caching

Without optimization, every read follows this path:

1. Parse ID from URL: a7x3k
2. Query database: SELECT * FROM pastes WHERE id = 'a7x3k'
3. Check if expired: compare expires_at with current time
4. Fetch content from object storage: GET /a7x3k
5. Return content to user

At 1,200 reads/sec, the database handles metadata lookups fine — simple PK queries. But every read also fetches from object storage (~50ms), and since pastes are immutable (content never changes after creation), we're fetching identical bytes 100 times on average. This is exactly the pattern edge caching solves.

The Key Decision: How Do We Speed Up Reads?

Our Choice: CDN for Content + In-Memory Cache for Metadata

CDN handles the heavy lifting of serving immutable text content at edge locations. Redis cache holds metadata for fast existence and expiry checks when the application server is involved (writes, deletes, edge function fallbacks).

How Does the CDN Integrate with the Domain?

The write path returns a short URL like pb.example/a7x3k. How does that request reach the CDN?

Our Choice: CDN in front of the domain. Single domain, zero extra latency, and the app server is removed from the read path entirely for content requests.

CDN Caching Behavior

CDNs use a pull-through pattern: on the first request for a paste, the CDN fetches from the object storage origin, caches the response at the edge location, and serves all subsequent requests from that edge's cache. This is ideal for Pastebin because:

• Most pastes are accessed shortly after creation (shared in an issue or chat), then traffic tapers off
• The CDN naturally keeps "hot" content cached and lets "cold" content expire
• Paste content is immutable — the cached version is always correct

CDN Configuration:

• TTL: Match paste expiry duration. For non-expiring pastes, use a reasonable default (24 hours). The CDN re-fetches from origin after TTL expires.
• Cache key: The URL path (/a7x3k) serves as the natural cache key.
• Invalidation on delete: Call the CDN purge API to remove the paste from all edge caches.

Handling Expired Pastes

With CDN-only reads, there's no app server to check expires_at on every request. Expired paste enforcement relies on the background cleanup job:

1. Cleanup job runs on schedule (e.g., nightly or hourly), finds pastes where expires_at < NOW()
2. Deletes content from object storage (saves storage costs — we pay per GB stored)
3. Purges CDN cache for deleted paste IDs
4. Marks paste metadata as GONE in the database

After cleanup, requests for expired pastes return 404 from object storage (object doesn't exist). Before cleanup runs, expired content may still be served — this brief window is acceptable for most use cases. For immediate enforcement (e.g., sensitive credentials), see the deep dive on edge KV enforcement.

The baseline write rate is 12 writes/sec — trivially low. But what happens when AWS has a major outage and thousands of developers simultaneously paste error logs? Write QPS jumps from 12 to 1,200 — a 100× spike. The application servers are stateless and horizontally scalable (spin up more instances behind the load balancer), but all instances write to the same database.

Understanding the Bottleneck

At 1,200 writes/sec with each write taking ~50ms (object storage + DB insert), you need 60 concurrent database connections just to maintain throughput. A typical connection pool has 100 connections — the pool fills up, requests queue, timeouts cascade, and users see "Service Unavailable." The database is the bottleneck, not compute.

The Key Insight: Users Don't Need Synchronous Persistence

Users need a URL immediately. They don't need their paste's metadata queryable in the same request. The actual content is already in object storage (durable) before the database write. This decoupling insight unlocks a much more efficient spike handling strategy.

Our Choice: Message Queue Buffering + Rate Limiting as Safety Valve

The slight delay in metadata availability is invisible to users. The paste is readable via CDN the moment the object storage write completes.

Our current design handles 1M DAU comfortably with a single database, CDN, and minimal infrastructure. But what if the product scales by 10×, 100×, or 1000×? Each order of magnitude introduces new bottlenecks.

Recalculating the Numbers

Summary: What Triggers Each Change

Key principle: Don't over-engineer for scale you don't have. Our 1M DAU design is intentionally simple — single database, CDN, no sharding, no queue. Add complexity only when a specific bottleneck materializes and is measurable.

A developer accidentally shares a paste containing database credentials. They realize the mistake after 10 minutes and set the paste to expire immediately. But with the current design, the paste remains accessible until the next cleanup job runs — potentially 15 hours later. For sensitive content, this is unacceptable.

Why Can't We Check Expiry on Every Request?

The read path goes: User → CDN Edge → Object Storage. There's no application server in this path. No component checks expires_at. The object exists in storage, so it gets served. The cleanup job is our only enforcement mechanism, and it runs on a schedule.

We need real-time expiry checks without routing every read through an application server — which would defeat the purpose of CDN caching.

Moving the Check to the Edge

Modern CDNs offer edge compute — lightweight functions that execute at edge locations before requests reach origin. Instead of checking expiry at our servers, we check it right where the request arrives. But the edge function needs to know when each paste expires. Where does it get this information?

key: "a7x3k"
value: {"state": "ACTIVE", "expires_at": "2026-03-18T12:00:00Z"}

Our Choice: Edge KV

Edge KV provides sub-millisecond state lookups without touching the backend. The edge function runs before every request reaches origin:

Updated Write Path with Edge KV

Creating a paste now includes an edge KV write:

1. Generate random ID
2. Write content to object storage
3. INSERT metadata to database (PK uniqueness check)
4. Write to edge KV: id → {state: "ACTIVE", expires_at: "..."}
5. Return URL to user

The edge KV write propagates to global edge locations within ~50ms. By the time the user shares the URL, edges worldwide can enforce the expiry.

What Happens to the Cleanup Job?

The cleanup job's role changes:

Edge KV is now the source of truth for access control. The cleanup job saves storage costs by deleting objects we're no longer serving, but correctness doesn't depend on it.

In the previous deep dive, we introduced edge KV to enforce expiration. Now consider deletion: a user deletes a popular paste with millions of cached copies across 200+ CDN edge locations. The obvious approach — delete the edge KV entry and purge the CDN cache — creates two serious problems.

Problem 1: The Thundering Herd

Imagine a viral paste getting millions of views is deleted:

1. We delete the edge KV entry and call CDN purge
2. CDN purge propagates across 200+ edges (takes seconds)
3. After purge, all edges simultaneously have cache misses
4. Edge functions check edge KV → "not found" → all forward to the app server
5. App server is slammed with requests it rarely handles

The edge function can't distinguish "deleted" from "never existed" or "propagation delay" — when the KV entry is missing, it must fall back to the origin. Deleting the entry removes our edge protection precisely when we need it most.

Problem 2: ID Reuse

If we delete all records of a paste (object storage, database, edge KV), the ID a7x3k becomes available. The ID generator might accidentally reissue it. A user who bookmarked pb.example/a7x3k would see completely different content — a violation of URL stability that erodes trust.

With 218 trillion possible 8-character base62 IDs and only 90M active pastes, accidental collision is astronomically unlikely. But defensive engineering eliminates the possibility entirely — and the cost (keeping a database row) is negligible.

The Solution: Tombstones

Instead of deleting the edge KV entry, update it to a tombstone — a state marker that says "this paste was intentionally removed":

key: "a7x3k"
value: {"state": "GONE"}

When the edge function checks:

1. Edge KV lookup → finds state: GONE
2. Returns 410 Gone immediately
3. No app server hit, no database query, no thundering herd

The tombstone absorbs the traffic spike. Even with millions of requests per hour, the backend stays quiet.

Tombstone Lifecycle

Tombstones don't need to persist forever. Traffic to deleted content cools off exponentially:

• First hour: potentially millions of requests (if viral)
• After 24 hours: a trickle of stragglers
• After 72 hours: effectively zero

After traffic dies off, we remove the tombstone (edge KV entry with 72-hour TTL) and rely on cheaper protections: CDN negative caching (cache the 404 response for 60 seconds) and request coalescing (multiple simultaneous cache misses share one origin fetch).

What Gets Deleted vs. What Stays

The Complete Delete Flow

After 72 Hours (Tombstone Expires):

1. Edge KV: No entry for a7x3k → miss
2. Request forward to origin → object already deleted → 404
3. CDN caches the 404 for 60 seconds (negative caching)
4. No thundering herd because traffic has died down to zero

Why 410 Gone Instead of 404 Not Found?

• 404 is ambiguous — could mean typo, never existed, or propagation delay
• 410 explicitly signals "this resource existed and was intentionally removed"
• 410 tells caches this status is permanent — safe to cache aggressively

For privacy-sensitive applications, you might prefer 404 for everything (to avoid confirming a paste ever existed). The tombstone still works — you simply return 404 instead of 410.