Detailed Component Design

Component 1: Key Generation

Responsibility: Produce a unique, unguessable 7-char key for every new paste.

How it works: Random base62 (0-9A-Za-z) key, 7 chars → 62⁷ ≈ 3.5 trillion combinations. For ~1M pastes/day (~12 writes/sec), collision probability is negligible; on the rare collision, regenerate and retry.

Uniqueness (race-safe): On write, INSERT with a UNIQUE constraint on key. If the DB returns a duplicate-key error, the app generates a new key and retries. No scanning — the index makes it an instant lookup, and the constraint guarantees correctness even with concurrent creates.

Unguessable: 3.5T keyspace makes enumeration infeasible → satisfies the NFR that "the URL is the access control."

Scaling: Stateless — any app server generates keys independently; no shared store needed at this scale.

Trade-off: Random+retry is simplest and unguessable. Sequential base62 counter is collision-free but guessable (violates the NFR). Pre-generated key pool is fastest but adds a store — overkill at 12 writes/sec.

Component 2: Read / Cache Path

How it works: GET /pastes/{key} → check Redis first. Hit → return content (no DB/S3 touch). Miss → read metadata from Postgres → fetch content from S3 → populate Redis → return.

What gets cached: the content blob, keyed by paste key, with a TTL ≤ the paste's expiry. Hot pastes then serve in ~1ms from memory.

Cache-miss path: Postgres holds metadata; S3 holds content. Both are only hit on a cold read, so the read-heavy load (10:1) is absorbed by Redis.

Scaling: Add Redis nodes / shard by key hash; read replicas cover cache-miss reads.

Failure scenario — thundering herd: a viral paste's cache entry expires → thousands of requests hit the DB at once. Mitigate with a lock-on-miss (one request rebuilds the entry, others wait/brief-stale) or serve slightly-stale content while one worker refills.

Graceful degradation: if S3 is slow or the DB is down, cached pastes still serve — only cold reads and new writes fail.

Component 3: Cross-cutting Concerns

Idempotent creation: client sends an idempotency key; if a retry arrives with the same key, return the original paste URL instead of creating a duplicate. (Alternatively, dedupe on a content hash within a time window.)

Rate limiting: token bucket per IP (~10 creates/min) to stop abuse/spam — important since creation is anonymous.

Expiry / cleanup: a cleanup worker scans the expires_at index, deletes expired rows from Postgres and their content from S3, and evicts the cache entry.

Trade-offs to name aloud: content in S3 vs. inline in Postgres (independent scaling + cost); Redis eviction policy (LRU) since it's a cache, not the source of truth; eventual consistency is fine here — a just-created paste may 404 briefly on a lagging replica, which is acceptable for this product.

Submissions

Displaying Solutions with Scores Ranging from 1 to 10

Submissions

Displaying Solutions with Scores Ranging from 1 to 10