We deleted the reconciliation step from a data migration and replaced it with a single timestamp. Nothing overlaps, so nothing needs matching.
That's the ending. Here's how we got there — and the short version of part 1, for anyone arriving without it:
We were moving short-term leave data from a legacy processor to a new service. To avoid double-counting during the overlap, a step called heal matched a new row against a legacy-seeded one on value shape — (employee_id, date, leave_type, unit, amount), the only columns the two feeds shared — and appended a compensating negative entry. Two days of bug fixing later we measured it: 9 of the 13 compensating rows it had ever written in production were wrong, and 238 of 244 overlapping employee-days reconciled exactly with no compensation at all. Separately, the table's primary key (request_id, date) turned out not to be unique — one correction request can carry four entries across two dates, and our upsert silently published 16 hours where the truth was 8.
Two problems: rows that shouldn't be matched, and rows that shouldn't collide.
Before
