How Would You Design Pastebin?
Learn how to design Pastebin: short key generation, blob storage, read-through caching, and expiry for a write-once service.
Expected Interview Answer
Pastebin is a text-snippet sharing service built around three core pieces: a short unique key generator for each paste, an object store or blob-friendly database for the paste content, and a read-heavy caching layer in front, since pastes are written once and read very many times.
On write, the service generates a short unique key (via base62 encoding of an auto-increment ID, or a hash of the content), stores the paste body in a blob store or key-value store optimized for large text values, and records metadata (creation time, expiry, visibility) in a lightweight index. Reads dominate the traffic pattern, so a CDN or in-memory cache (Redis/Memcached) sits in front of the blob store, serving hot pastes without hitting the backing store at all, with cache invalidation driven by TTL rather than explicit updates since pastes are immutable once created. Expiry is handled by either a background sweeper job that deletes expired pastes on a schedule or lazy deletion on read (check expiry, return 404 or trigger cleanup), and abuse controls (rate limiting per IP, max paste size, optional captcha) protect the write path since it is open and anonymous.
- Short-key generation keeps URLs compact and shareable
- A read-through cache absorbs the vast majority of traffic since pastes are immutable and read far more than written
- Separating blob storage from metadata keeps the write path fast and the index small
- TTL-based expiry avoids unbounded storage growth for temporary pastes
AI Mentor Explanation
Pastebin is like a stadium’s public noticeboard where anyone can pin a printed note under a short reference tag, and thousands of fans walk by to read it afterward without needing to know who wrote it. The board assigns each note a compact tag (short key) the moment it is pinned, so people just glance at the tag to find the right note. Because far more fans read the board than post to it, staff keep photocopies of the most-viewed notes at the entrance (cache) instead of making everyone walk to the actual board. Notes with a “remove after” date are cleared automatically once expired, exactly like a Pastebin snippet’s TTL.
Step-by-Step Explanation
Step 1
Accept the paste and generate a key
On write, base62-encode an auto-increment ID (or hash the content) into a short unique key for the URL.
Step 2
Store body and metadata separately
Write the large text body to a blob/key-value store and small metadata (createdAt, expiry, visibility) to a lightweight index.
Step 3
Serve reads through a cache
Put a CDN/in-memory cache in front so hot pastes are served without hitting the backing store, since content is immutable.
Step 4
Expire and clean up
Delete expired pastes via a background sweeper or lazily on read, and rate-limit the anonymous write path against abuse.
What Interviewer Expects
- Recognizes the read-heavy, write-once access pattern and designs caching accordingly
- Describes a concrete short-key generation approach (base62 counter or content hash)
- Separates blob storage for paste bodies from a lightweight metadata index
- Addresses expiry (TTL) and abuse protection (rate limiting on the anonymous write path)
Common Mistakes
- Not exploiting immutability — proposing complex cache invalidation for content that never changes
- Ignoring abuse/rate limiting on an anonymous, public write endpoint
- Using a single monolithic table for both the huge paste body and small queryable metadata
- Skipping short-key collision handling (retry on duplicate key from a hash-based scheme)
Best Answer (HR Friendly)
“I would design Pastebin around the fact that a snippet is written once and read many times: generate a short unique code for each paste, store the text itself in a storage system built for large blobs, and put a fast cache in front so that popular pastes are served instantly without repeatedly hitting the storage layer. I would also make sure old or expired pastes get cleaned up automatically and that anonymous posting is rate-limited to prevent abuse.”
Code Example
async function createPaste(content, ttlSeconds) {
const id = await counter.nextId()
const key = toBase62(id) // e.g. "aZ9k3"
await blobStore.put(`paste:${key}`, content)
await metaStore.insert({
key,
createdAt: Date.now(),
expiresAt: ttlSeconds ? Date.now() + ttlSeconds * 1000 : null,
})
return key
}
async function getPaste(key) {
const cached = await cache.get(`paste:${key}`)
if (cached) return cached
const meta = await metaStore.findByKey(key)
if (!meta || (meta.expiresAt && meta.expiresAt < Date.now())) {
return null // expired or missing
}
const content = await blobStore.get(`paste:${key}`)
await cache.set(`paste:${key}`, content, { ttlSeconds: 3600 })
return content
}Follow-up Questions
- How would you generate short keys without collisions at very high write volume?
- How would you handle a paste that suddenly goes viral and gets millions of reads?
- Would you use content hashing (like Git) instead of an auto-increment counter, and what trade-offs does that bring?
- How would you support custom/vanity short URLs alongside auto-generated ones?
MCQ Practice
1. Why is a cache especially effective in front of a Pastebin-style service?
Since content never changes after creation and is read far more often than written, a cache can serve most traffic without invalidation complexity.
2. What is a common technique for generating short paste keys?
Base62 encoding of an incrementing ID (or a content hash) produces compact, URL-safe short keys.
3. Why should paste body content and paste metadata typically be stored separately?
Splitting a small, queryable metadata index from large blob storage keeps lookups fast and the storage tier optimized for its data shape.
Flash Cards
What is Pastebin’s dominant access pattern? — Write-once, read-many — content is immutable and reads vastly outnumber writes.
How are short keys typically generated? — Base62-encoding an auto-increment counter, or hashing the paste content.
Why is caching so effective here? — Because pastes never change after creation, so cached copies never go stale until TTL expiry.
How is paste expiry usually handled? — A background sweeper job or lazy deletion on read once the TTL has passed.