Part 3 · 1 chapters · ~8 min

Backend System Design

The backend design round arc, requirements and non-functional targets, back-of-the-envelope estimation, API and data model first, high-level architecture, choosing two or three deep dives, scaling only where the numbers demand it, failure modes and operations, and prompts worked in outline (payments, URL shortener, rate limiter, chat, notification system, feed).

Estimation and prompts

code

back-of-envelope: a payments service
  2,000,000 transfers/day ÷ 86,400 s ≈ 23/s average; peak (salary day, 10×) ≈ 230/s
  each transfer: ~6 ledger rows × 200 B ≈ 1.2 KB → 2.4 GB/day → ~0.9 TB/year before indexes
  → one Postgres primary + replicas handles the writes; plan partitioning by month for history (Postgres P7)
  → the hard parts are correctness (idempotency, double-entry, reconciliation), not throughput

prompt	deep dives worth choosing	Learna
payments / wallet	idempotency keys, double-entry ledger, rail timeouts and unknown states, reconciliation	Ledgers, API Design P8, Workflows
rate limiter	algorithm choice, Redis Lua atomicity, distributed limits	Backend Algorithms P1, BSD P2
chat	connection gateway, fan-out, ordering per conversation, presence	BSD, Kafka
notification system	priority queues, provider failover, dedupe, user preferences	Workflows, Kafka
news feed	fan-out on write vs read, celebrity accounts, ranking cache	BSD, Redis
URL shortener	id generation (base62, collisions: birthday bound), cache, analytics	Discrete P4, Redis

BACKEND SYSTEM DESIGN, THE ARC

requirements → numbers → simple design → deep dives → failure

swipe the figure sideways, or tap expand for full screen

1/4

requirements

Separate functional ("send money to a bank account") from non-functional (99.95% availability, no double debits, p99 under 300 ms). The non-functional ones drive the design.

functional + non-functionalNFRs drive design