Concepts
The log is the database (Aurora)
Intuition
Imagine an accounting ledger in which you only write down each change, one line after another, never rewriting the old pages. The current balance of any account can be rebuilt by rereading the entries, so the ledger of entries is the truth, and any summary you keep on another sheet is just a convenience that can be redone at any time. If several people keep copies of this ledger, you only need to send them the new lines, not whole recopied sheets.
How it works
In Aurora, the database tier sends only redo log records over the network: no data pages are written, whether in the background, at checkpoint or on cache eviction. The storage tier receives these records and applies the log to materialize pages, continuously or on demand; from a correctness standpoint, the materialized pages are just a cache, and the log is the database. Records are batched by Protection Group and sent to the 6 copies across 3 AZs, and the database waits for acknowledgment from a write quorum of 4/6; only receiving and persisting the record stays on the synchronous path, the rest is asynchronous. Instead of 2PC, each record gets an increasing LSN, and storage computes the VDL, the point up to which the volume is durable; commit is asynchronous and the transaction is only acknowledged to the client when the VDL reaches its commit LSN. Reads in normal operation go to a single segment that is already complete up to the read-point, with no read quorum. In recovery there is no replaying of the log from a checkpoint: the database queries a read quorum of each PG, recomputes the VDL and truncates the records above it. The same idea of an ordered log, replicated and acknowledged by majority appears in Raft, where an entry is committed once it is replicated on a majority; in Aurora, the order comes from the LSNs issued by the single writer, and durability comes from the 4/6 quorum of each PG, without 2PC.
In practice
The paper shows the practical effect: in the 100 GB SysBench write-only test, Aurora sustained 35 times more transactions than mirrored MySQL, with 0.95 I/Os per transaction versus 7.4, even while amplifying writes six times. Recovery usually takes under 10 seconds, and the read replicas, which share the same volume, lagged by 5.38 ms at 10,000 writes/s versus 300 s on MySQL. Consider this design when the bottleneck of a cloud database is the network between compute and storage: send only the log, let storage materialize pages, and use quorum and LSNs instead of multi-phase commit protocols.
Use it in a design
Practice the cases that rely on this concept in the System Design school.