The latest articles on DEV Community by Sverre Senneset (@queuey). https://dev.to/queuey https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3888966%2Fe48149e5-452f-4a08-bb34-302134b7efeb.png https://dev.to/queuey en Sverre Senneset Mon, 20 Apr 2026 12:39:27 +0000 https://dev.to/queuey/why-database-backups-dont-fix-integration-failures-and-what-actually-does-4dgn https://dev.to/queuey/why-database-backups-dont-fix-integration-failures-and-what-actually-does-4dgn <h2> Why database backups don’t fix integration failures (and what actually does) </h2> <p>I used to treat integration failures as data problems.</p> <p>Restore the database.<br><br> Re-run the job.<br><br> Patch the gap. </p> <p>It works — until it doesn’t.</p> <p>Because most of the time, the data isn’t missing.</p> <p>The event just never made it where it needed to go.</p> <h2> The gap no one owns </h2> <p>Most systems are built around state.</p> <p>Databases, backups, snapshots — all focused on <em>what the data looks like</em>.</p> <p>But integrations are about <em>how data moves</em>.</p> <p>A typical flow:<br> ERP → Service A → Service B → API</p> <p>Now imagine:</p> <ul> <li>ERP emits an <code>order.created</code> event </li> <li>Service A forwards it </li> <li>Service B times out </li> <li>No retry is triggered </li> <li>The upstream system assumes success </li> </ul> <p>Nothing crashes.<br><br> No alerts fire.</p> <p>Until someone notices the order was never fulfilled.</p> <h2> Why backups fall short </h2> <p>When this happens, teams usually:</p> <ul> <li>restore a backup </li> <li>re-run a job </li> <li>patch data manually </li> </ul> <p>But backups only restore state.</p> <p>They don’t tell you:</p> <ul> <li>what failed </li> <li>what never arrived </li> </ul> <p>And they can’t reconstruct a missing event.</p> <h2> The real problem: delivery </h2> <p>At some point it becomes clear:</p> <p>This isn’t a data problem.<br><br> It’s a delivery problem.</p> <p>Most systems rely on:</p> <ul> <li>webhooks </li> <li>ad hoc retry logic </li> <li>logs spread across services </li> </ul> <p>When something fails mid-flight, debugging becomes guesswork.</p> <p>And if something is lost entirely, recovery becomes manual.</p> <h2> A different approach: replay </h2> <p>Instead of restoring state, replay flow.</p> <p>If events are:</p> <ul> <li>captured </li> <li>stored </li> <li>replayable </li> </ul> <p>You can recover without guessing.</p> <p>Not by re-running jobs.<br><br> Not by patching data.</p> <p>But by replaying what actually happened.</p> <h2> What this enables </h2> <ul> <li>Re-deliver only failed events </li> <li>Trace what happened to a specific event </li> <li>Apply updated retry or routing policies </li> </ul> <p>Recovery becomes predictable — assuming idempotent consumers.</p> <h2> Trade-offs </h2> <ul> <li>Storage overhead </li> <li>Idempotency requirements </li> <li>Architectural shift </li> </ul> <h2> Final thought </h2> <p>If you can’t replay what happened between your systems,<br><br> you don’t really have a recovery strategy.</p> <p>You have a snapshot.</p> backend distributedsystems devops api