Design Pastebin

Pastebin looks almost identical to Design a URL Shortener on the surface — a short code maps to something bigger — but the "something bigger" is the whole difference: a URL shortener stores a tiny string, while Pastebin stores arbitrarily large blocks of text. That single change pushes the interesting design decision from "how do I generate the short code" to "where does the actual content live." Following the framework from How to Answer a System Design Interview Question.

1. Requirements

Functional:

• A user submits a block of text and receives a short, shareable URL.
• Visiting that URL displays the original text.
• Optionally support an expiration time and view-count limits.

Non-functional:

• Reads dominate writes, same as a URL shortener, since a paste is written once and can be viewed many times.
• Pastes can be large (up to several megabytes of text), which — unlike a URL shortener's short strings — makes storage layout a real design question rather than an afterthought.

Scale estimate: assume 1M new pastes/day, averaging 10KB each — about 10GB/day, or roughly 3.6TB/year. That's small enough for a single well-chosen storage system, but large enough that storing full paste bodies directly in the same database row as metadata is worth questioning.

2. API Design

POST /pastes
  body: { content: string, expires_at?: timestamp }
  returns: { paste_id: string }

GET /pastes/{paste_id}
  returns: { content: string, created_at: timestamp }

3. Data Model

The key design decision: separate metadata from content.

pastes (metadata — relational database)
  paste_id     VARCHAR   PRIMARY KEY
  content_key  VARCHAR          -- pointer into object storage
  created_at   TIMESTAMP
  expires_at   TIMESTAMP NULL

(content itself — object storage, e.g. S3)
  key: content_key -> raw paste bytes

Storing large text blobs directly as database rows works at small scale but degrades a relational database's performance and backup/replication story as row sizes grow — the standard fix, and the one worth naming explicitly in an interview, is storing the metadata (small, structured, frequently queried) in a database and the content itself (large, opaque, rarely queried by field) in dedicated object storage built for exactly this shape of data.

4. High-Level Design

System Design Lab

A cache in front of the read path still applies exactly as it did for the URL shortener — a small number of pastes tend to get disproportionately viewed (something posted to a forum, for instance), and caching those hot reads avoids repeatedly re-fetching the same large blob from object storage.

5. Deep Dive: content-addressable storage and deduplication

A detail worth raising proactively: many pastes are accidental or intentional duplicates (the same error message pasted by many different users, for instance). Instead of generating content_key as a random ID, hashing the paste's content itself and using that hash as the key means identical content is automatically stored only once — a second identical paste just gets a new paste_id in the metadata table pointing at the same existing content_key, and object storage is never written to twice for the same bytes. This is the same content-addressing idea underlying Checksums and version control systems, applied here for storage efficiency rather than integrity checking.

The one thing this requires getting right: paste deletion or expiration can no longer just delete the blob outright, since another paste's metadata might still point at that same content_key — a reference count (or a periodic garbage-collection pass checking for orphaned content) is needed before content storage is actually freed.

6. Tradeoffs

Separating metadata from content adds a second storage system and an extra network call to assemble a full response (fetch metadata, then fetch content) — more moving parts than one database holding everything. It buys a metadata database that stays small and fast regardless of how much paste content accumulates, and a content store built for exactly the large-object access pattern pastes actually have.

Content-hash deduplication has its own small cost: freeing storage now requires knowing a piece of content has zero remaining references, not just that one paste expired, which means expiration can no longer just delete a blob immediately — it has to decrement a reference count (or wait for a periodic garbage-collection pass) first. That's a deliberate, small amount of added bookkeeping in exchange for never storing the same popular paste's bytes twice.

Storing content in object storage vs. inline in the database: pros and cons

Separate object storage

• ✓Metadata database stays small and fast regardless of total paste volume
• ✓Object storage is purpose-built for large blobs and scales independently
• ✓Content-hash deduplication is straightforward to add on top

Content inline in the database

• ✕Large rows degrade query performance and slow down backups/replication over time
• ✕Database storage costs more per byte than object storage built for this purpose
• ✕Couples metadata and content scaling together, when their access patterns actually differ

Further Reading

• AWS — Amazon S3 Object Storage — a concrete reference for the object storage model this design relies on.
• System Design Primer — Design Pastebin — a widely referenced worked solution covering the same core design.