Design Pastebin — System Design Interview Practice
Design a web service where users can store plain text and share it with others via a generated URL. Work through the requirements, architecture trade-offs, and an interactive design review.
Concepts and architecture decisions to consider
- web servicesConcept to explore
- storageConcept to explore
- cachingConcept to explore
- text storageConcept to explore
Interview prompt
Design a Pastebin-like service where users create text pastes, receive short URLs, optionally protect or expire them, and read them reliably at internet scale.
- Separate immutable paste content from mutable metadata, abuse controls, and read caching.
- Choose an ID strategy that is compact, non-sequential to users, and safe under retries.
- Use object or blob storage and a CDN for popular reads while keeping the write path durable.
- Explain expiration, privacy, abuse prevention, deletion, and cache invalidation.
Requirements and scale assumptions
- Create a paste from text and return a short, shareable identifier.
- Read a paste by identifier with optional syntax highlighting and raw-content access.
- Support public, unlisted, and password-protected pastes with optional expiration.
- Allow owners and moderators to delete content, report abuse, and audit administrative actions.
- A successful create must durably retain the paste before its URL is returned.
- Target p95 below 100 ms for a cache hit and below 300 ms for a metadata-backed read.
- Reads should scale independently from writes and tolerate hot pastes without database overload.
- Expired or deleted content must stop being served even when edge and application caches are warm.
- 20 million new pastes per day, 2 billion reads per day, and 50,000 peak read requests per second.
- Most pastes are small text blobs, but a strict size limit prevents oversized uploads from becoming a storage path.
- A small fraction of links become extremely hot after being shared publicly.
- Retention varies from minutes to permanent; expired content is deleted or moved to a cold tier by policy.
- Paste create rate: ~230/s avg — 20M creates per day with burst capacity for campaigns.
- Read latency: p95 <=100ms hit — Popular immutable content should be served from edge or regional cache.
- Cache hit rate: >95% hot — Track hit rate by region and evict on deletion or policy changes.
- Expiry accuracy: 100% enforced — The serving path checks expiry and deletion state, not only cache TTL.
Key entities
- PastepasteId, ownerId, contentHash, visibility, expiresAt, createdAt, status
Immutable or versioned text content with ownership and expiry.
- ShortAliasalias, pasteId, createdAt, status
Unique lookup key mapped to a paste without exposing database identifiers.
- AccessPolicypasteId, visibility, passwordHash, allowedUsers, expiresAt, version
Versioned access and retention policy.
- AbuseScanscanId, pasteId, scannerVersion, findings, status, completedAt
Asynchronous moderation and malware/secret scan result.
Data flow
- 1. Create and validate a pasteThe API checks size, expiry, visibility, abuse policy, and idempotency, then stores content and alias metadata durably.
- 2. Resolve a short aliasEdge and cache look up the alias; cache misses read metadata and content, recheck expiry and access policy, and return a bounded response.
- 3. Scan and moderate asynchronouslyA queue sends content to secret, malware, and abuse scanners; a policy result can hide a paste without deleting audit evidence.
- 4. Expire and delete safelyExpiry workers write tombstones, evict aliases, and delete content by lifecycle policy while preserving ownership and deletion audit.
- 5. Measure reads without hurting redirectsClick/read events leave the serving path and are aggregated asynchronously with privacy and retention controls.
Deep dives and trade-offs
- Alias resolution and cache safetyFor the Pastebin-like paste service, an alias must never resolve to expired, deleted, or unauthorized content. Design for the failure case where a hot alias, abuse burst, or cleanup lag must not expose content or take down reads; keep retries, versions, and repair state explicit. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
- Expiry, deletion, and lifecycleFor the Pastebin-like paste service, an alias must never resolve to expired, deleted, or unauthorized content. Keep this concern off unrelated request paths and partition it by the Pastebin-like paste service access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
- Abuse scanning without blocking readsFor the Pastebin-like paste service, an alias must never resolve to expired, deleted, or unauthorized content. Keep this concern off unrelated request paths and partition it by the Pastebin-like paste service access key. Expose freshness, version, lineage, or audit metadata so operators and clients can distinguish current, pending, and degraded state.
- Mutable paste versus immutable versionsPrefer immutable content versions and an explicit latest pointer when editing is required. In-place edits complicate cache invalidation, audit, and link consistency.
- Synchronous scan versus fast creationAccept within size/policy limits and quarantine or label content while deep scanning asynchronously. Blocking every create on scanners raises tail latency and couples availability to third parties.
- Long cache TTL versus revocationUse short policy-aware TTLs and targeted invalidation for password, delete, and abuse changes. A long TTL improves hot reads but can serve revoked or expired content.