Why this is in my collection

From the publisher:

Data is at the center of many challenges in system design today. Difficult issues need to be figured out, such as scalability, consistency, reliability, efficiency, and maintainability. In addition, we have an overwhelming variety of tools, including relational databases, NoSQL datastores, stream or batch processors, and message brokers. What are the right choices for your application? How do you make sense of all these buzzwords?In this practical and comprehensive guide, author Martin Kleppmann helps you navigate this diverse landscape by examining the pros and cons of various technologies fo

Highlights

  • Derived data can always be regenerated from the system of record — Kleppmann's split between source-of-truth data and derived views (caches, indexes, materializations) is the deepest theoretical backing MDDE has: if something is derivable, its production should be mechanical, not artisanal.
  • The data model is the most consequential decision in the system — his data-models chapter argues that how you represent data shapes everything built on top; the same primacy-of-the-model claim, argued from application architecture instead of warehousing.
  • Schema-on-read just moves the schema, it never removes it — implicit structure in the reading code is still structure, only unmanaged; the sharpest available rebuttal to schemaless magic.
  • Declarative beats imperative because intent enables optimization — SQL's declarative nature lets the system choose the execution; the identical logic by which a declared model plus rules lets a generator choose the implementation.
  • The log turns the database inside out — treating an append-only event log as the backbone from which all state is derived mirrors Data Vault's insert-only, audit-first philosophy at the infrastructure level.
  • Reliability is designed in, not patched on — fault tolerance comes from architecture (replication, immutability, idempotence) rather than operator heroics; structure beats magic at the systems layer.
  • Integrity constraints outlive any single technology — Kleppmann closes by arguing correctness must be an end-to-end, application-level concern; effectively rules as the third pillar, stated by a distributed-systems researcher.

Highlights on this page are generated with the help of AI.