Backfill
A one-off pass that fills in data the new code expects but the old data lacks — running the new logic across everything that already exists.
The word doubles as a hiring term (backfilling a departed role), which is why it confuses people in mixed company. In engineering it almost always means the data run.
You add a field, ship the code that writes it, and every row created before today is missing it. A backfill computes the value for the old rows so the feature does not lie about history.
Three properties make one safe. It should be idempotent, so running it twice does not double anything. It should be resumable, because it will fail halfway on the one row with the odd data. And it should be observable — a count of what it touched and what it skipped, or you cannot tell success from a silent no-op.
The related trap: a backfill that takes minutes in staging takes hours in production, and while it runs you have two shapes of data live at once. Code that assumes the new shape has to tolerate the old one until the run finishes.
- Idempotent
Safe to run twice. The second run changes nothing beyond what the first did, which is what makes retries, replays and backfills survivable.
- Drift
When two things that should agree quietly stop agreeing — the doc and the code, the counter and reality, staging and production.
- Soft delete
Marking a record deleted rather than removing it, so an accident is recoverable. The cost is that every query has to remember to exclude it, and one that forgets shows users their own deleted data.