DATA ENGINEERING · OPERATIONS BRIEF
Data flow recovery checklist
A completed fictional example, then a 6-item grid to prepare the recovery of one specific flow. The checklist shows what must be checked, by whom, and where to find the evidence; it does not replace test results.
2-page checklist: page 1, completed fictional example; page 2, 6 fields to fill in directly in the PDF. Typed text is kept when you save.
Completed example (fictional)
| Item | Fictional example: batch of orders |
|---|---|
| Business intent and key | Record a batch of orders. Stable batch key, identical across attempts of the same request; a new business request gets another key, even if some values are equal. |
| Destination and reference state | Orders database: it is authoritative on the batch state. Known period during which a replay is supported and the key is retained. |
| Writes and effects | Order insert, notification, invoice, write in another system: each effect identified and tested within its own scope; write protected by a uniqueness constraint, a transaction or the destination API’s idempotency. |
| Concurrency and lost-confirmation tests | Confirmation lost after the write, two concurrent attempts, same key with modified content, late replay, partial effect, uncertain destination result; fictional data and expected results defined in advance. |
| Recovery and exceptions | Initial result retrievable through a usable reference; outputs to suspend if the result is uncertain; reconciliation before any new attempt; same key with different content: agreed rejection, conflict or correction workflow. |
| Owner, evidence and review date | Named owner for exceptions; evidence per effect: request, key, expected and observed result; date of the next review (fictional example: no real date). |
Blank grid
| Item | Your flow |
|---|---|
| Business intent and key | |
| Destination and reference state | |
| Writes and effects | |
| Concurrency and lost-confirmation tests | |
| Recovery and exceptions | |
| Owner, evidence and review date |