Designing Data-Intensive Applications 2nd Edition · Chapter 1
Trade-Offs in Data Systems Architecture
Frames the whole book: there are no solutions, only trade-offs. Walks the four biggest trade-offs in data systems — operational vs analytical, cloud vs self-hosting, distributed vs single-node, and business needs vs the rights of people in the data — while building the vocabulary (OLTP/OLAP, warehouse, system of record, derived data) the rest of the book depends on.
Most software behind everyday apps is data-intensive: managing data is the hard part, not raw computation. We assemble such systems from standard parts — databases, caches, search indexes, stream and batch processors — and the craft is choosing and gluing them, This chapter’s premise: no option is simply better; every choice trades one virtue for another.
The chapter walks four big trade-offs: operational versus analytical systems (OLTP vs OLAP, warehouses, lakes, systems of record vs derived data), cloud versus self-hosting (build-vs-buy for operations, cloud native architecture, storage/compute separation), distributed versus single-node systems (why distribute, why not to — microservices, serverless), and the needs of the business versus the rights of the people in the data (GDPR, data minimization).
Opening quote (Thomas Sowell): “There are no solutions: there are only trade-offs. But you try to get the best trade-off you can get, and that’s all you can hope for.”
01 — Operational Versus Analytical Systems
Three kinds of people want different things from the same data: backend engineers, business analysts (BI), and data scientists. Operational systems are where data is born; analytical systems hold a read-only copy optimized for heavy processing. From the divide grew data engineers and analytics engineers.
OLTP: point quires by key, low-latency per-record writes, fixed query repertoire in app code, current state , GB-TB. OLAP: scans of enormous record counts returning aggregates, ad hoc queries by analysts with SQL/BI tools, history over time, TB-PB. Hybrids: product/real-time analytics (Pinot, Druid, ClickHose).
The data warehouse: a separate read-only copy from all OLTP systems, fed by ETL/ELT — solving silos, schema mismatch, production impact, and access. Lakes serve data scientists with raw files (sushi principle); lakehouses add warehouse tables on lake formats; reverse ETL pushes analytical outputs (ML models) back into operations.
The second distinction: system of record (authoritative, written first, exactly once, normaalized) vs derived data (rebuildable copies: caches, indexes, materialized views, trained models). It’s a property of usage, not the tool — annotate your architecture diagrams with it. The catch: syncing derived data access systems is your problem (data pipelines, chaper 11).
My Notes
The “fossil word” story of transaction is memorable, Biggest shift for me: treating system-of record vs derived-data as a lens I can apply to any architecture diagram — ask “what is authoritative and what could be rebuilt?” and confusion dissolves.
02 — Cloud Versus Self-Hosting
“Build or buy” hides two questions: who writes it, who operates it. Spectrum: bespoke → self-hosted (on-prem or IaaS VMs) → SaaS. Economics: predictable load + in-house expertise favors self-hosting (37signals’ math: >$500k/yr on managed DBs and searhc); bursty load and unfamiliar systems favor the cloud’s elasticity.
Cloud downsides are all about lost control: no custom features, waiting on outages, no OS metrics/logs/debuggers, forced migrations, vendor lock-in, sanctions risk, trusting providers with data.
Cloud native ≠ managed service. Cloud native systems compose services from services (Snowflake on S3), and the deep shit is separation of storage and compute: local disks become ephemeral caches; durability lives in object storage; virtual disks (EBS) are the transitional compromise. Multitenancy shares hardware across customers - utilization wins, isolation costs.
Operations transformed rather than vanished: capacity planning became financial planing machine toil became service integration, DevOps/SRE replaced per-machine administration. Some responsibilities never leave your building: app security, service interaction, load watching, performance debugging.
My Notes
The 37signals counter-example keeps “cloud by default” honest. The line “capacity planning becomes financial planning” reframed how I think about cloud bills - and “find the quota caps before they find you” is an operational lesson in disguise.