Pastebin — Naive (Single Service + SQL)

Designing a Pastebin-like service is one of the most approachable system design interview questions, yet it covers fundamental concepts that apply to far more complex systems: unique ID generation, blob storage, TTL-based expiry, read-heavy traffic patterns, and the cache-versus-no-cache trade-off. The naive approach is the essential starting point because it establishes the baseline that makes the improvements in cached and object-storage architectures measurable and concrete.

The core challenge is deceptively simple: a user pastes text, the system generates a unique URL, and anyone with that URL can view the paste. Under the hood, the system must handle 1 million new pastes per day (approximately 12 writes per second average, 500 peak) and 10 million views per day (approximately 116 reads per second average, 4,500 peak). The 10:1 read-to-write ratio is the defining characteristic of this workload. Most pastes are small — 5KB average — but the system must support up to 10MB pastes for large code dumps or log files. Read latency must stay under 200ms at p99.

In the naive approach, every operation hits a single PostgreSQL database. Paste creation generates a UUID-based ID, inserts the content into a `pastes` table, and returns the URL. Paste viewing queries the same table by primary key — a B-tree indexed lookup completing in approximately 12ms under light load. There is no cache, no CDN, no background workers, and no separation between the read and write paths. The architecture has exactly four components: Client, Load Balancer, PasteService, and PasteDatabase.

The fatal flaw of this approach is the database becoming both the read and write bottleneck simultaneously. At 4,500 peak reads per second, each requiring a 12ms database query, the connection pool (100 connections) approaches saturation. Large pastes stored via PostgreSQL TOAST add vacuum overhead that further degrades performance. Without a cache to absorb the 90% of reads that are for recently created or popular pastes, every single view pays the full database round-trip cost.

This template makes the database bottleneck visible and quantifiable. Run the simulation at increasing RPS and watch PostgreSQL utilization climb past 90% while the PasteService sits idle at under 10% CPU. The comparison with the RDBMS+Cache variant demonstrates how a single Redis cache-aside layer — achieving a 90% hit rate — reduces database reads from 4,500/sec to just 450/sec, transforming an overloaded system into a comfortable one. Pastebin design appears in interviews at companies like GitHub, GitLab, Hastebin, and virtually any company that needs to reason about text storage, URL generation, and read-heavy access patterns.

The naive Pastebin system is a four-component linear architecture: Client, Load Balancer, PasteService, and PostgreSQL database. There is no cache, no CDN, no object storage, and no separation between the read and write paths. Every request follows the same path through all four components.

All traffic enters through the Load Balancer, which distributes requests across PasteService pods using round-robin. The Load Balancer adds approximately 1.5ms of routing latency and supports up to 5,000 RPS — well above the system's actual ceiling, which is determined entirely by the database. Both paste reads and paste creates flow through the same LB and service — there is no CQRS split, no API Gateway, and no authentication layer.

The PasteService is a stateless REST API running on 2 pods with 50 threads each, providing 100 concurrent request capacity. It handles two operations: (1) paste creation — validate content size (max 10MB), generate a UUID-based paste ID encoded in Base62 for URL friendliness, INSERT into the pastes table, return the paste URL; (2) paste read — SELECT from the pastes table by paste_id, check if the paste has expired (compare expires_at to current time), validate password if protected, return the content. Service processing time is approximately 8ms, but total response time is dominated by database latency.

PostgreSQL stores a single table: pastes. It contains both metadata (paste_id, syntax hint, expires_at, password_hash, created_at) and content (the paste text itself) in the same row. The paste_id column has a B-tree index enabling approximately 12ms indexed reads under light load. Large pastes exceeding 8KB are automatically handled by PostgreSQL TOAST (The Oversized Attribute Storage Technique), which compresses and stores them out-of-line. TOAST is transparent to the application but adds vacuuming overhead that degrades performance over time.

The system has no redundancy at the data layer. A single PostgreSQL primary handles all reads and writes with no read replicas. If the database fails, both reads and writes stop entirely. There is no failover, no replication, and no backup read path. The concrete scaling ceiling is approximately 500 sustained RPS — at this point, the 100-connection pool approaches saturation with 12ms read latency and 50ms write latency competing for the same connections. Beyond 500 RPS, queue depth increases, latency spikes, and the system degrades rapidly.