Visibility and durability ask different questions

Change the assumption: L fails after acknowledging v9 but before R receives it. If policy promotes R without recovering that write, the acknowledged address may disappear from available state. Local persistence cannot equal survival of losing that node.

A survival promise must specify required acknowledgments and eligible leadership candidates. Involving more participants can add waiting and communication dependencies. A lagging replica creates a visibility problem; promotion without the acknowledged write adds loss risk. Their remedies and costs differ.

Losing T1's response introduces another situation: an unknown outcome. A timeout cannot reveal whether acknowledgment occurred. A stable operation identity and result lookup can help if the system maintains that contract. A new identity per attempt makes repetition of the same intention harder to recognize.

Transactions protect a defined set of decisions

Suppose editing an address must also append an audit record. If both belong to one commit, write them atomically in storage providing that guarantee. Test failure between the steps and absence of partially applied state.

That cannot automatically make a later replica read current. Write atomicity and read visibility concern different parts of the operation. Nor should an isolation-level name become a promise about every concurrent sequence. Examine documented behavior and the anomalies your application must prevent.

Kleppmann challenges simplified labels in Please stop calling databases CP or AP, emphasizing precise definitions and operation-specific properties. For profiles, asking who reads what after which acknowledgment clarifies more than assigning two letters to the whole database.

Derived data expands the contract

A profile may feed a search index and report. Updating the primary record need not update every representation simultaneously. If search returns Street A while the editing screen displays Street B, establish whether this is permitted delay or a product-contract violation.

Batch processing can rebuild a report from a bounded input set; stream processing follows arriving changes. Both require decisions about repetition, completeness and format evolution. Understand how results are produced and rebuilt without claiming one mechanism always replaces the other.

Identify the reference source, how far derivation has progressed and failure policy. Reprocessing may recover results while repeating external effects if a consumer cannot distinguish reconstruction from a new action. The path between persisted data and user experience deserves the same care as the initial write.

An exercise connecting concepts and verification

Choose a controlled environment and actual replication configuration. Record version, topology and acknowledgment policy. Reproduce replica-application lag, execute the write and compare session reads. Separate read-your-writes expectations from any node-failure survival promise.

Then simulate a lost response and leadership change through available mechanisms. Observe whether the application recovers the outcome or communicates uncertainty. Never use an experiment to assert guarantees its environment was not configured to provide.

This review's table executes none of those tests. It helps write expectations and locate missing evidence. Success in one scenario cannot cover every failure; retain explicit cases, assumptions and verification limits.

Strengths and criticism

The comparative method is its strength. You gain questions distinguishing write costs, latency, availability and recovery. These challenge both popularity-based product choices and the belief that one mechanism solves every risk.

Breadth is also a limitation. Understanding concepts differs from operating a migration or recovering a database under pressure. Readers may acquire vocabulary before operational judgment. Combine reading with documentation, experienced operators and experiments exposing configuration consequences.

Products and examples in the 2017 edition reflect their period. Use concepts as a starting point and check deployed-version documentation before transferring a product-specific assertion. Historical comparisons cannot establish a managed service's current behavior or automatically include its contractual limits.

Intended readers and reasons to wait

I recommend it to developers familiar with basic SQL, indexes and process communication. Running a large cluster is unnecessary, but observing a write, read and network failure helps. Beginners can start with those experiments and return to chapters as questions emerge.

If the immediate need is learning table queries or fixing a connection, introductory material and database documentation may pay off sooner. Avoid introducing distribution merely to practice the book. Simple storage meeting the contract avoids coordination your product may not need.

Implementing DDD helps formulate business invariants. Release It! complements operational failure analysis. Clean Architecture discusses dependencies. DDIA investigates mechanisms that must sustain those decisions; separating layers cannot select a read guarantee.

A reading plan and verdict

Describe a real operation: inputs, query, write and visible consequence. Read storage and replication to question data paths. Study transactions and failures next, revising the timeline. Explore derived processing when search, reporting or another separately maintained result exists.

For each alternative, state a desired guarantee, an accepted cost and an assumption requiring tests. Compare this with current implementation before proposing replacements. This reading practice carries no promise that it ends with a database migration.

I recommend the first edition for the reasoning it develops. The desired result is distinguishing data not yet visible, lost data and an unknown outcome, explaining how each reaches users. Sound decisions begin with clear promises and willingness to verify what sustains them.