SYSTEM DESIGN · QUESTION 113
How would you design a paste-sharing service?
On this page
I would clarify paste size, visibility, expiration, and traffic patterns. The write path validates and stores content under a random or allocated identifier with metadata; the read path resolves the identifier and serves cached content with suitable cache headers. Add abuse controls, rate limits, expiration cleanup, and access checks. If pastes are large, separate metadata storage from blob storage.
LET'S MAKE IT SIMPLE
First, the idea in plain English
A paste service accepts text and returns a short link. Later, someone uses that link to retrieve the content. Writes and reads may have different traffic patterns, and public content can be abused, so the service needs validation, expiration, and access rules.
A USEFUL COMPARISON
Picture it this way
A library assigns a short call number to a note and stores the note separately from its catalog entry. The catalog points to the content and records when it should be removed or who may read it.
FOLLOW THE JOURNEY
Separate paste metadata, content storage, and read caching
Trace creation, identifier allocation, storage, retrieval, and expiration.
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Public links need lifecycle and privacy controls.
A validated paste is stored as content with metadata and an identifier; read requests resolve metadata, check access, retrieve content, and use cache or expiration rules.
How to read this visual
This simplified visual highlights the main relationships. In practice, the exact design depends on the requirements; Public links need lifecycle and privacy controls.
UNDER THE HOOD
How it works, step by step
Validate submission
Check size, encoding, visibility, and abuse policy.
Why it matters: Unbounded or unsafe content can create operational risk.
Allocate identifier
Create an unguessable or collision-checked key.
Why it matters: Identifiers must resolve uniquely and respect privacy expectations.
Store content and metadata
Persist content separately when size or access patterns justify it.
Why it matters: Storage layout affects cost and retrieval.
Serve and expire
Check access, cache appropriately, and remove expired content.
Why it matters: Public links need lifecycle and privacy controls.
OUTSIDE THE TEXTBOOK
A practical example
A user submits a code snippet with a seven-day expiry. The service validates its size, stores content, records visibility and expiry metadata, then returns an opaque link. Read requests check expiration and visibility before serving; cleanup removes old content and associated cache entries.
GO A LITTLE DEEPER
Technical details that matter
- Random identifiers reduce enumeration but do not replace authorization for private pastes.
- Expiration should apply to storage, caches, and derived previews.
- Content-type handling and output escaping prevent stored content from being interpreted as executable markup.
MAKE A GOOD CHOICE
When is this useful?
- Sharing snippets, logs, or short text with a controlled lifetime.
- Design practice around key allocation, caching, and blob storage.
- Read-heavy immutable content services.
A static object store with signed URLs may be sufficient for a private or internal use case.
WATCH OUT FOR
Common misunderstandings
- Assuming an unguessable URL makes sensitive data fully private.
- Serving submitted HTML without safe content handling.
- Deleting storage objects but leaving cached copies available.
REAL-WORLD TRADE-OFFS
Limitations and failure cases
- Public paste services attract spam and malicious content.
- Expiration and cache invalidation must stay consistent.
- Large pastes can increase storage and abuse costs.
WHAT TO REMEMBER
Key takeaways
- 1Define visibility, expiry, and size constraints first.
- 2Validate content and treat identifiers as references, not authorization.
- 3Coordinate storage, metadata, caching, and cleanup.
PRACTICE THE FOLLOW-UP
What might an interviewer ask next?
How do you make a paste private?
Require authorization or a scoped access token and enforce it on every read; an opaque URL alone is not a complete privacy boundary.
How do you handle expiration with caching?
Set cache lifetime no longer than the content’s valid lifetime and invalidate or deny cached access when expiry or permissions change.
SAY IT OUT LOUD
How to explain this in an interview
“I would clarify size, visibility, expiration, and traffic. The write path validates content, allocates a unique opaque key, and stores content with metadata. Reads check access and expiry before returning cached or stored content. I would also rate-limit submissions, escape output, and coordinate deletion with caches and previews.”
Connect this question to the roadmap topic it supports.