Designing Data-Intensive Applications

Why it stuck

I came to this book after my first monolith-to-services refactor and realised I'd been making replication and consistency decisions by accident. Kleppmann gives you the vocabulary to make them on purpose.

Where it shows up in my work

• Chapter 5 (Replication) is the reason the quote service in the A sub-100ms personalised surge-pricing engine for a US food marketplace reads from a pre-aggregated profile instead of the primary: the staleness is bounded and named.
• Chapter 7 (Transactions) is behind the FOR UPDATE locking on anomaly rows in Vedico: realtime fleet tracking for telecom field operations; two pings must not open two incidents.
• Chapter 11 (Stream processing) shaped the event-driven split in Prompt-to-app BaaS: generating full-stack stores on AWS, then cutting the bill by 76%: consumers are idempotent, so replays are boring.
• The multi-tenant trade-offs in Designing Multi-Tenant Database Architectures are essentially the book's partitioning chapter applied to SaaS.

Quotes I keep

"The limits of my language mean the limits of my world." Kleppmann quoting Wittgenstein, on why naming consistency guarantees matters.

What I disagree with

Very little, but the book predates the vector-database wave. The retrieval layer in Advanced RAG Architecture: Graph, Vector, Redis, and PostgreSQL needed the same thinking about indexes and consistency that the book applies to search; it just isn't in there yet.