Files
buzz/docs
Luke Tornquist 9263cda845 docs: specify durable data backfills (#7326)
## Why

Data backfills need a durable contract outside schema migrations. The
contract must survive crashes and support automatic or manual operation
without adding version-selection machinery.

## What

- Define one PostgreSQL-backed lifecycle for finite data repair
- Treat the stable backfill ID as the only durable execution and
readiness identity
- Use eventually consistent, idempotent registration; compatible workers
compete for one exclusive claim
- Require bounded batches, atomic mutation and checkpoint commits,
generation fencing, and validation before completion
- Define all four migration and automatic-backfill configurations
- Define the authorized admin API and honest client projection

## How

A backfill captures one immutable upper bound, processes finite batches,
and commits each target mutation with its checkpoint. PostgreSQL owns
lifecycle state, claims, progress, and completion.

Registration order and build metadata do not choose a definition.
Compatible processes are interchangeable. A material behavior change
requires a new stable ID. The orchestrator does not resolve different
behavior registered under one active ID. Diagnostic validation on
completed rows records only its bounded outcome and audit; it does not
create an execution claim.

The spec now starts with a six-step mental model and follows the
operator flow. It removes repeated requirements and cuts the document
from 614 lines and 4,835 words to 474 lines and 3,656 words.

## Risk

Low. This PR changes documentation only. It commits Buzz to a design
contract, but it does not add runtime, schema, configuration, or
protocol behavior.

## Testing

No manual runtime testing. A fresh full-spec review checked the
lifecycle, safety rules, four configuration cells, admin contract, and
production-seam conformance requirements. `git diff --check` and the
repository file-size policy pass at
`13681664674d4667b181a6211f012090fa40a2cf`.

## Bigger picture

The design keeps the relay as orchestrator, a focused backfill crate as
domain owner, and `buzz-db` as narrow transaction infrastructure. It
removes deployment generations and definition precedence from the
implementation plan.

Generated with Codex

---------

Signed-off-by: tornquist <tornquist@squareup.com>
Co-authored-by: Codex <noreply@openai.com>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 13:05:41 -04:00
..
2026-07-21 17:16:23 +00:00