Pastebin — RDBMS with Cache (Postgres + Redis)

The RDBMS with Cache approach is the production-standard architecture for Pastebin-style services at moderate scale. It solves the fundamental bottleneck of the naive approach — every read hitting the database — by introducing a Redis cache-aside layer that absorbs 90% of read traffic. This is the architecture most interviewers expect candidates to arrive at after identifying the database bottleneck in the naive design.

The system handles the same workload as the naive variant: 1 million new pastes per day and 10 million views per day, with a 10:1 read-to-write ratio. The critical difference is how reads are served. Instead of every read querying PostgreSQL (12ms average latency), 90% of reads hit Redis first (2ms average latency). Only the remaining 10% — cold pastes not in cache — fall through to PostgreSQL. This reduces database read load from 4,500 reads/sec at peak to approximately 450 reads/sec, well within a single PostgreSQL instance's capacity.

The cache-aside pattern works as follows: on paste creation, PasteService writes the paste to both PostgreSQL (durable storage) and Redis (immediate cache population). On paste read, PasteService checks Redis first. On cache hit (90% of the time), the paste is returned in approximately 2ms. On cache miss, PasteService queries PostgreSQL (approximately 12ms), writes the result back to Redis for subsequent reads, and returns the paste. Redis entries have TTL matching the paste's configured expiry, so expired pastes auto-evict from cache.

The 90% cache hit rate is driven by the Zipfian access pattern inherent to Pastebin-style services: recently created pastes receive the vast majority of views. When someone creates a paste and shares the URL, the recipients typically view it within minutes to hours. The write-through on creation ensures the paste is in Redis before the first read arrives. Older pastes that fall out of cache via LRU eviction are rarely accessed, so the miss penalty is infrequent.

This architecture handles up to approximately 5,000 sustained RPS — a 10x improvement over the naive approach. The database is no longer the bottleneck; instead, the ceiling is determined by Redis capacity and the remaining 10% of reads that hit PostgreSQL. For most Pastebin-style services with moderate traffic, this is sufficient. When traffic exceeds 5K RPS, or when paste sizes regularly exceed 8KB (causing PostgreSQL TOAST overhead), the Object Storage variant with S3 and DynamoDB provides the next level of scalability.

This template demonstrates the most important caching pattern in system design interviews: cache-aside with write-through. Candidates who can articulate why the 90% hit rate works (Zipfian access), how cache invalidation is handled (TTL-based), and when this approach stops being sufficient (large pastes, global scale) demonstrate strong system design fundamentals.

The RDBMS with Cache Pastebin uses five components organized in a linear pipeline with a cache branch: Client, API Gateway, Load Balancer, PasteService, Redis Cache, and PostgreSQL Database. The API Gateway handles authentication and rate limiting. The Load Balancer distributes traffic across PasteService pods. PasteService is the central coordinator that routes between Redis and PostgreSQL based on cache hit/miss.

All traffic enters through the API Gateway, which performs JWT authentication (approximately 3ms), rate limiting (8,000 RPS cap with headroom), and request validation. The API Gateway routes all valid requests to the Load Balancer, which distributes across PasteService pods using round-robin. The Load Balancer adds approximately 1.5ms of routing latency and has 15,000 RPS capacity — 3x headroom above peak traffic.

PasteService runs on 4 pods with 100 threads each, providing 400 concurrent request capacity. The write path is straightforward: generate a UUID-based paste ID, persist to PostgreSQL (approximately 50ms INSERT), write to Redis cache (approximately 2ms SET), and return the paste URL. The key optimization is the write-through to Redis — the paste is available in cache before the first reader arrives, preventing a thundering-herd cache miss on newly created popular pastes.

The read path implements the cache-aside pattern. PasteService first checks Redis using the paste_id as the cache key. On hit (90% of reads), the paste content and metadata are returned from Redis in approximately 2ms. On miss (10% of reads), PasteService queries PostgreSQL by paste_id (approximately 12ms indexed read), checks TTL expiry, validates password if protected, writes the result back to Redis (backfill), and returns the content. The backfill ensures subsequent reads for the same paste hit the cache.

Redis runs on 2 nodes for high availability with 13GB memory each. The cache key pattern is paste:{id} mapping to paste content plus metadata. LRU eviction handles memory pressure when the working set exceeds cache capacity. Each cache entry has a Redis TTL matching the paste's configured expiry, so expired pastes auto-evict without explicit invalidation. The expected working set is approximately 4,500MB — comfortably within the 13GB per-node capacity.

PostgreSQL stores the pastes table with a B-tree index on paste_id. With 90% of reads absorbed by Redis, the database handles only approximately 450 reads/sec at peak — easily manageable for a single primary with 2 read replicas. The 2 replicas provide redundancy and additional read capacity for cache-miss scenarios. Background cleanup jobs purge expired rows nightly, as PostgreSQL has no native TTL mechanism.