Pastebin

Assume 30M new pastes per month, a 50:1 read to write ratio, 30 days per month, a 10x peak multiplier, and a default retention window of 12 months after TTL cleanup. Average metadata is 1 KB per paste.

Assume 85 percent of pastes are small enough to store inline with an average body size of 8 KB. The remaining 15 percent are large pastes with an average compressed object size of 512 KB. Enforce a maximum paste size such as 10 MB for anonymous users and higher limits for trusted accounts.

• Writes: 30M creates per month divided by 30 days is 1M creates per day. 1M divided by 86,400 seconds is about 11.6 writes per second, rounded to 12.
• Reads: with a 50:1 read to write ratio, average read traffic is about 580 reads per second.
• Peak: using a 10x multiplier gives about 120 write QPS and 5,800 read QPS.
• Inline content: 85 percent of 30M is 25.5M small pastes. 25.5M times 8 KB is about 204 GB per month.
• Object content: 15 percent of 30M is 4.5M large pastes. 4.5M times 512 KB is about 2.3 TB per month.
• Retention: monthly content of about 2.5 TB for 12 months gives about 30 TB raw before database replication, object-storage durability overhead, compression differences, and lifecycle cleanup.
• Metadata: 30M records per month times 12 months is 360M records. At 1 KB each, metadata is about 360 GB raw.
• Cache: if a few million popular small pastes drive most public reads, caching them at roughly 8 to 10 KB each plus memory overhead requires tens of GB, so plan 30 to 50 GB across the replicated hot cache tier.
• Keyspace: 62 to the power of 8 is about 218 trillion combinations. That provides large safety margin and makes random guessing harder than short sequential keys.

• pastes.paste_key is the primary key and must support a single point lookup.
• pastes.owner_user_id, created_at supports account dashboards and deletion workflows.
• pastes.expires_at supports TTL cleanup, background sweeps, and lifecycle reporting.
• pastes.scan_status, updated_at helps scanners and moderators find pending or suspicious content.
• paste_views_daily.paste_key, event_date supports analytics dashboards.
• Do not index the full paste body. Use content hashes and external scanning systems for abuse workflows.

A paste may belong to one user, but anonymous pastes have no owner. Analytics aggregates and abuse events reference paste_key and can be rebuilt or retained separately from the serving record. The read path should not join users, analytics, and abuse tables unless the paste is private or policy requires an access check.

A distributed key-value database such as DynamoDB, Cassandra, Bigtable, or FoundationDB fits the serving path because reads are point lookups by paste key. Keep small inline content below item-size limits and move larger bodies to object storage such as S3, Azure Blob Storage, or Google Cloud Storage.

Use conditional writes to reserve paste keys and atomic conditional updates to consume burn-after-read pastes. Store analytics in an append-friendly stream and OLAP store instead of updating the paste row on every view. Object storage lifecycle policies can expire large bodies after the metadata TTL passes.

The central Pastebin tradeoff is where to store the text body. Inline storage is fast and simple for small pastes because a single cache or database lookup returns metadata and content. It also simplifies atomic creation and deletion.

Large inline bodies are dangerous. They inflate database storage, reduce cache efficiency, increase replication cost, and make hot rows expensive to move. A practical design sets an inline threshold such as 32 KB or 64 KB. Content above that threshold is compressed and stored in object storage, while the metadata row stores object URI, size, hash, and content location.

This differs from a URL shortener. A shortener stores a small redirect target and returns a Location header. Pastebin stores user content and must handle body size, rendering safety, object fetches, and content moderation.

Paste keys have two jobs: uniqueness and reasonable resistance to guessing. A sequential counter encoded as base62 is easy to implement, but it exposes creation volume and lets attackers enumerate unlisted pastes. That is a serious privacy issue because unlisted links are often treated as share-by-link resources.

Random base62 keys with enough length are the better default. Eight characters provide about 218 trillion combinations, which is far more than the expected number of active pastes. The create path can generate a candidate and perform a conditional insert, retrying on rare collisions. A pre-generated key pool also works if operational complexity is acceptable.

Custom aliases should be optional and subject to stricter validation. They are easier to guess, can impersonate brands or users, and require atomic reservation just like generated keys.

Expiration can be enforced lazily on read by checking expires_at and returning 410 Gone when the deadline has passed. Background cleanup and object-storage lifecycle policies reclaim space later. Correctness should not depend on cleanup running exactly on time.

Burn-after-read is stricter. Two clients may request the same paste concurrently, so the service must consume the read atomically before returning content. Use a conditional update such as remaining reads equals 1 and status equals active, then set remaining reads to 0 and status to burned. Only the request that wins returns the body.

Do not cache burn-after-read content in a shared CDN or Redis entry. A stale cache hit would bypass the atomic consumption step and leak the paste multiple times.

Caching is safe only when the access policy is cache-safe. Public, clean, non-password, non-burn pastes with future expiration can be cached at CDN and Redis with TTL capped by the paste expiration time. Negative caching for unknown keys should be short to avoid hiding newly created pastes after replication delay.

Private, password-protected, pending-review, and one-time pastes should bypass public caches and usually use Cache-Control: private, no-store. For unlisted but public pastes, cacheability is a product decision: caching improves cost and latency, but shared caches must not expose analytics or owner metadata.

Hot viral pastes can become single-key hot spots. Mitigate with CDN, replicated cache entries, request coalescing on misses, compression, and serving large object bodies directly from edge caches when allowed.

A paste service can host phishing kits, malware snippets, stolen secrets, spam lists, and offensive content. The create path should apply rate limits, size limits, content hashes, deny lists, and lightweight synchronous checks. Heavier scanners run asynchronously and can mark a paste suspicious or blocked.

Rendering is also security-sensitive. Syntax highlighting must treat paste content as untrusted text, escape HTML, block script execution, and avoid storing unsafe highlighted HTML unless the sanitizer is trusted. Raw views should send text/plain and avoid content sniffing.

Scanner results affect cache invalidation. If a paste is later blocked, the system must evict CDN and Redis entries or maintain a small blocked-key cache checked before serving cached content.

View analytics are useful, but the read path should not synchronously update a counter in the paste row. Popular pastes would create write hot spots, and analytics outages would become read outages.

Emit view events asynchronously after the policy decision. Consumers aggregate by paste key and time bucket, using approximate unique visitor sketches where needed. Product dashboards can tolerate eventual consistency and freshness indicators.

For privacy, avoid storing raw IP addresses longer than necessary. Prefer coarse geography, hashed or truncated identifiers, retention limits, and tenant-specific access controls for detailed analytics.

Alternative one is to store all content in a relational database. It is easy for a prototype but becomes expensive and slow as large pastes accumulate.

Alternative two is to store every body in object storage, including tiny pastes. It simplifies database size but adds object fetch latency to the common case and complicates atomic creation.

Alternative three is a document-sharing system with full ACLs, collaboration, search, and versioning. It is more powerful but overbuilt for temporary snippets and anonymous sharing.

Do not use Pastebin as a secure secret manager, source-control system, or long-term compliance archive. If the content is highly sensitive, needs strong identity-based access, version history, legal retention, or guaranteed deletion semantics, design a secure document store or secrets platform instead.