Batch Load Ledger

A batch load ledger records which logical batches have committed to a target. A retry can check that record and avoid applying the same load twice. Bind the ID to immutable input, not just a convenient date; a second extraction for the same date may contain different data.

Suppose batch B contains orders A and C. Write B’s identity and insert those rows in the same supported transaction. If insertion fails, both changes roll back. If commit succeeds but its response is lost, a retry finds B and skips the already applied effect. Reusing B for orders A and D must be rejected or treated as explicitly new work.

Use non-null identities and database uniqueness, and test concurrent workers. The ledger does not deduplicate order A arriving again under batch E. It also cannot atomically cover an external email unless a separate compatible protocol does so. When rebuilding or restoring the target, restore compatible ledger state; an old ledger against an empty table can cause all retries to be skipped.

Reference: SQLite transaction boundaries.