Design Pastebin

CDN (CloudFront / Fastly)

Key generation, object storage, and read caching paths are straightforward. This keeps the design lean and cost effective.

Paste reads are globally distributed and content is immutable once created. The CDN caches rendered HTML and raw text pages at edge locations using the paste URL path as the cache key, applying a time to live of min(expiry_remaining, 24 hours) for expiring pastes and 7 days for permanent pastes.

API Gateway

The API gateway centralizes authentication, rate limiting, and request routing before traffic reaches internal services. It enforces token bucket rate limiting by client IP, allowing 10 pastes per hour for anonymous users and 100 pastes per hour for authenticated accounts. Anonymous creation requests require a CAPTCHA challenge during burst traffic, while the gateway handles SSL termination and uniform request validation.

Key Generation Service (KGS)

At Pastebin scale, random key generation often suffices, whereas a dedicated Key Generation Service becomes necessary when write throughput increases, as explored in URL Shortener.

The Key Generation Service pre allocates 8 character Base62 identifiers in batches from a theoretical space of 218 trillion keys, persisting them in a dedicated key pool database partitioned into unused_keys and used_keys tables. During paste creation, application workers atomically pop a preallocated batch of keys from memory. This approach eliminates runtime collision checks, generates non sequential identifiers that make enumeration impractical, and maintains submillisecond key allocation times while local batches remain available.

Write Service

The write path must remain durable and idempotent. The Write Service receives the paste payload, expiration policy, syntax language, visibility, and idempotency key, acquires a pregenerated unique key from the local KGS buffer, and uploads the compressed body to S3 under s3://pastebin-content/{key_prefix}/{key}. Once the S3 upload succeeds, it commits the metadata record and a paste created row to the MySQL outbox in the same transaction. The API returns 201 Created after the database commit. If the database transaction fails after the S3 upload, the object is treated as an orphan candidate and cleaned by the lifecycle worker or retry path. For authenticated users, the idempotency key is scoped to the user so retries return the original result without creating a second paste. The server derives idempotency_scope from the authenticated user or anonymous request principal. Anonymous requests that need retry safety therefore use a stable request principal together with the idempotency key.

Read Service

The read path is the latency critical workflow that demands multi tier caching. The Read Service resolves visibility before serving a cached document. Public and unlisted requests use the standard Redis key. Private requests require owner authorization and use an auth aware Redis key. On a cache miss, the service queries MySQL to confirm that the paste exists, verifies authorization when the paste is private, and checks that it has not expired. Burn after reading pastes bypass all caches and use an atomic MySQL consume claim so only one request can obtain the right to read the content. For a standard paste, the service fetches compressed content from S3 and asynchronously warms Redis with a time to live of min(paste expiry, 1 hour) before returning the content with syntax highlighting.

Safe Rendering and Raw Content

Rendered paste pages must HTML escape user supplied content and use a strict Content Security Policy so pasted code cannot become stored cross site scripting. Raw responses should use text/plain with MIME sniffing disabled. Syntax highlighting must operate on escaped text and never execute the pasted content.

Content Storage: S3 vs Database

Large pastes are stored in S3, while compact metadata stays in MySQL for fast indexed key lookups. Paste bodies reach up to 10 MB, making them ill suited for relational database storage where large text blobs bloat buffer pools, degrade index traversal, and complicate backup schedules. Amazon S3 provides 11 nines durability and cost effective object storage, allowing MySQL to retain only compact 500 byte metadata records that index cleanly. Compressing text payloads with zstd prior to S3 upload yields 3x to 10x storage reduction and significantly curtails bandwidth expenses.

Cleanup Worker

Background workers pull expired records and report completion without blocking user traffic. A background cleanup worker runs on an hourly schedule to query expired records from MySQL in manageable batches. For each expired batch, the worker marks records expired when needed, deletes the underlying objects from S3, purges eligible metadata rows from MySQL, evicts matching keys from Redis, and writes a paste-deleted event to the MySQL outbox. The Outbox Relay then publishes that event to Kafka for downstream analytics and cache invalidation. The delete path immediately invalidates Redis entries after the MySQL transaction and publishes the deletion through the outbox. The Cache Invalidation Worker retries Redis invalidation when needed and purges public CDN objects. Origin metadata and expiration checks are authoritative immediately, while public CDN invalidation is asynchronous, so a bounded stale edge cache window can exist until the purge completes. A burn after reading paste uses the same deletion pipeline after its atomic consume claim, and if physical deletion fails after the claim, the consumed marker prevents another read while cleanup retries the storage deletion.

Analytics Worker

Analytics runs on a separate SLA from the hot path. The Analytics Worker consumes paste-created and paste-viewed events from Kafka and executes periodic micro batch inserts into ClickHouse. The View Count Batch Updater applies idempotent aggregate deltas to MySQL and updates or invalidates affected Redis entries after successful commits so cached view counts converge. This keeps view counts and trending metrics eventually consistent without imposing latency penalties or database write contention on the primary read path.

Event Bus Design (Kafka)

The event bus decouples producers from consumers and buffers traffic spikes across downstream subsystems. Database state changes use a transactional outbox so Kafka publication does not depend on a second non atomic write.

topics:
  paste-created:
    partitions: 16
    partition_key: paste_key
    retention_days: 7
    producers:
      - Outbox Relay (publishes after the MySQL metadata and outbox row commit)
    consumers:
      - Analytics Worker (batch writes to ClickHouse)
      - Content Moderation Scanner (asynchronous security scan)
    dlq: paste-created-dlq

  paste-deleted:
    partitions: 8
    partition_key: paste_key
    retention_days: 7
    producers:
      - Delete Service (writes the delete event to the MySQL outbox)
      - Cleanup Worker (writes the delete event to the MySQL outbox)
    consumers:
      - Analytics Worker
      - Cache Invalidation Worker (CDN and Redis)

  paste-viewed:
    partitions: 32
    partition_key: paste_key
    retention_days: 3
    producers:
      - Read Service (buffers every counted view in memory. Optional sampling is reserved for analytics telemetry only)
    consumers:
      - View Count Batch Updater (idempotent aggregate updates and Redis refresh/invalidation)

replication:
  replication_factor: 3
  min_insync_replicas: 2