Want to try it yourself first?
Answer each stage in the practice workspace, sketch the architecture, or run a timed mock, then come back here to compare.
The problem
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.
Watch: Design Pastebin with durable storage and read-time expiry
Store immutable text durably and index metadata by a unique paste ID. Acknowledge creation only after content and metadata succeed. Authorize private reads and enforce expiration before serving cached content. Use idempotency for retries, safely collect orphans, and add caching or partitioning for measured load.
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.
Common follow-up
A single paste becomes viral while the cache fails. How do you protect origin storage, preserve expiry and private-access rules, and recover without a refill stampede?