Review this. A team retired their batch path and now runs one streaming job per derived table. To keep replay always possible they set every topic to 400 days of retention with replication factor 3 across three zones, at 300 MB per second of total ingest. There are no snapshots of the derived stores because "the log is the backup". An erasure request for one customer arrived last week. What would you remove, what would you change, and what would you leave alone?

What is actually required

Three separate things have been collapsed into one setting: the ability to reprocess far enough back to correct the longest plausible logic bug, the ability to restore a derived store inside a stated recovery time, and the ability to erase one person's data. Retention serves the first. It serves the second badly and the third not at all.

What I would leave alone

One implementation of the logic. That is the real prize of collapsing to a single path, and every other criticism here is worth paying to keep it. Teams that argue themselves back into a parallel batch job to get backups have traded the thing that was working for a thing that could be bought more cheaply.

What I would change

Retention is not a backup, for an arithmetic reason. 300 MB/s is about 26 TB a day, so 400 days is roughly 10 PB of logical data and about 31 PB stored at replication factor 3. A job that sustains 1 GB/s of replay would take around 120 days to work through it. The team is paying for 400 days of a capability they cannot exercise inside any recovery objective anyone would sign.

The change is a pair:

1. Snapshot the derived stores on a schedule, so a restore is snapshot age plus replay from the snapshot's offset. That turns a 120-day worst case into hours and is what makes a recovery time objective statable at all.
2. Set retention per topic from its own reprocessing window - how far back a logic bug in that job could plausibly reach before someone notices - rather than from one global number. Most topics need weeks. Move the long tail to tiered storage so the broker disks shrink even where retention stays long, and accept that replay from the object tier is slower than from local disk.

The erasure request needs a different mechanism entirely. An append-only log cannot delete one person's records in place, and a compacted topic can only tombstone a key, which handles current state and not event history. The workable pattern is crypto-shredding: encrypt the per-subject fields with a key held in a separate key store, publish the ciphertext in the log, and satisfy erasure by destroying that subject's key. Erasure becomes a constant-time operation against the key store, the log stays immutable, and the retention argument and the privacy argument stop fighting.

How I would argue this in the review

Ask two questions and let the answers do the work. What is the recovery time objective for the largest derived store, and when was it last tested? If nobody has restored anything, the backup claim has never been exercised. How would you satisfy the erasure request that is already open? That one is not a hypothetical and it ends the discussion about whether the log is sufficient on its own.

When this is the wrong answer

For a pipeline whose derived stores are small and rebuildable in minutes - a few gigabytes of aggregates - snapshots are ceremony and replay genuinely is the restore path. The arithmetic flips on the ratio of state size to replay throughput, not on principle. And if no personal data ever enters the log, the crypto-shredding layer is cost with no benefit, so check before building it.