System design: Design Pastebin

easy

storage

databases

object-storage

Problem brief

A user submits a text snippet and receives a stable link. The design must keep successful writes readable, reject unauthorized or expired reads, and handle retries and popular pastes without confusing caching with durability.

Practice workspace

Guided practice or a locally saved 45-minute mock.

Guided practice

Mock interview

Step 1 of 7

Requirements

Define successful creation, visibility, expiry, size limits and what is out of scope.

Reference solution

Reference solution hidden

Try answering in the workspace above first. Reveal the full worked solution — data model, architecture, and trade-offs — whenever you want to compare.

Open the full solution page →

Reference solution walkthrough

The sections below are a worked solution, starting with requirements and continuing through the data model, architecture, and trade-offs. Use the practice workspace above first if you want to answer without seeing the reference.

Everything below this point is solution content.

Requirements

Version one creates and retrieves immutable text pastes. Assume a 100 KB size limit, optional expiration, and public or owner-only visibility. A successful create returns a link only after the content and its lookup metadata are durable. Editing, search and real-time collaboration are out of scope. Private means authorized access, not simply a difficult-to-guess identifier.

State sizing assumptions

Assume 1 million new pastes per day and a 10 KB average body: roughly 12 writes/second and 10 GB/day in decimal units. Thirty-day retention is about 300 GB of raw text, excluding replication, metadata and overhead. At 100 reads per write, average reads are about 1,200/second. Size peak traffic and hot keys separately; these are interview assumptions, not measured production requirements.

Data and API

POST /pastes accepts text, visibility and an optional expiry; GET /pastes/:id returns authorized, unexpired text. Initially a database can store small bodies directly. At larger payload volume, use private object storage for immutable bodies and a metadata database keyed by paste ID. Metadata includes object key, owner ID, visibility, creation time and expires-at. Generate random URL-safe IDs, enforce a uniqueness constraint, and retry collisions. Random IDs do not replace access checks.

Creation and retry safety

Authenticate where needed and validate size and limits. Write the immutable object, then commit metadata pointing to that stored object. Return success only after both writes succeed. They are separate storage systems, not a shared transaction: failed metadata creation leaves an invisible orphan to collect after a safe grace period. Use an owner-scoped idempotency key, bind it to the request, and persist its result with the metadata transaction so retries return the same paste. Failed object writes must not create readable metadata pointing to absent bytes.

Read path and caching

Look up metadata; reject missing, deleted or expired pastes. Check object-level authorization for private pastes before serving any cached body. Then fetch the body from cache or private object storage, filling the cache on a miss. Public immutable bodies suit content caching. Do not place private responses in a public shared cache or expose permanent object URLs that bypass the service. Escape text when rendering it as HTML.

Expiration is a read-time rule

The read path rejects content when now reaches expires-at. A cleanup worker may delete stored bytes later; its lag must not extend user-visible access. Bound cache lifetime by remaining paste lifetime, allowing for clock skew, and invalidate caches on early deletion. Immediate revocation requires reads through a trusted access path; a previously issued long-lived direct URL can defeat it.

Growth, failure and abuse

Run stateless app instances behind a redundant load balancer. Cache public content and control concurrent cache refills. Only shard metadata after measuring a bottleneck; partitioning does not solve a single hot key. Ensure newly created pastes are not read from lagging replicas. Use replication and tested backups for durable data, not the cache. Return explicit errors on durable-store failure and limit fallback load during cache outages. Monitor latency, errors, miss rates, cleanup lag and orphans. Add rate limits, size caps, abuse reporting and a moderation workflow appropriate to the product.