13 docs tagged with "ddia"

Most modern applications are **data-intensive**, not compute-intensive. The bottleneck is rarely the CPU — it's the amount of data, how fast it changes, and.

So far the book has focused on systems that handle requests as they arrive (OLTP) or read/write in real-time. But some of the most important data processing.

Batch processing has one problem: **latency**. A job that runs once a day means insights that are 24 hours stale. Stream processing is like a continuous batch.

The final chapter synthesizes everything in the book and looks forward. It addresses two questions:

Data models are probably the most important part of developing software — they shape not just how we write the code, but how we *think about the problem*. Each.

As an application developer, you usually just call your database and trust it to do the right thing. But to choose the right database and tune it properly, you.

Applications change over time — requirements evolve, new features are added, bugs are fixed. Your data model must evolve too. But in large systems, you can't.

**Replication** means keeping a copy of the same data on multiple machines (connected via a network). Reasons to replicate:

For very large datasets or very high query throughput, a single machine is not enough. **Partitioning** (also called sharding) breaks the data into.

Real applications are messy — the database can crash, network connections can drop, multiple clients write concurrently, and partial reads of partially updated.

Working with distributed systems requires a fundamentally different mindset than single-machine programming. In a single process, if something works once, it.

Chapter 8 cataloged everything that can go wrong in distributed systems. This chapter asks: **given all those failure modes, what guarantees can we actually.

Modern applications are not **compute-intensive** (CPU is rarely the bottleneck) — they are **data-intensive**. The real challenges are: