Diagrammatic

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. 1. Create and validate a pasteThe API checks size, expiry, visibility, abuse policy, and idempotency, then stores content and alias metadata durably.
  2. 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. 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. 4. Expire and delete safelyExpiry workers write tombstones, evict aliases, and delete content by lifecycle policy while preserving ownership and deletion audit.
  5. 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.
Diagrammatic — system design practice and architecture review.