# Why database backups don't fix integration failures

Most integration failures are not data problems. They are delivery problems. Event replay fixes what backups can't.

Author: Queuey
Published: 2026-04-13

Most integration failures are not data problems. They are delivery problems.

An event doesn't arrive, arrives twice, or arrives out of order — and nobody notices until something breaks.

An order never gets fulfilled. An invoice is sent twice. Inventory drifts out of sync.

The data exists, but the system state is wrong.

## Why backups don't help

Database backups were never designed to solve this.

They restore state. They tell you what your data looked like at a point in time.

They don't tell you what happened between systems.

And in modern architectures, that's where most failures live.

## How systems actually break

A typical integration flow looks like this:

```
ERP → Service A → Service B → API
```

Now imagine this sequence:

- **ERP emits an order.created event**
- **Service A processes it** and forwards it
- **Service B times out**
- **No retry is triggered**
- **The upstream system assumes delivery succeeded**

The event is lost.

Nothing crashes. No alerts fire. Everything looks "healthy".

Until someone notices the order was never fulfilled.

Now try fixing that with a database backup.

You can restore state — but you can't reconstruct the missing event.

## The problem isn't your data

The problem isn't your data. It's how it moves.

Most systems have no reliable way to observe, control, or replay that movement.

You don't have a data problem. You have a flow problem.

## Owning the delivery layer

Instead of chaining services together, introduce a system that owns delivery:

```
ERP → Event Layer → Targets
            ↓
   Replayable event history
```

In that model, every event is ingested, stored, delivered, and tracked from a single place.

This is the model Queuey is built on.

## Backup as replay

Traditional backups restore state. Replay lets you rebuild what actually happened.

Instead of asking "what did the database look like?", you can ask:

**What actually happened to this event?**

Queuey stores events as they move through your system, creating a replayable history of your integrations.

This allows you to:

- **Replay only failed events**
- **Re-deliver to specific targets**
- **Apply updated retry or routing policies**

This is not backup as storage. It is controlled recovery of event flows.

## What this gives you in practice

- **Deterministic recovery** — you know what will happen when you replay, assuming idempotent consumers
- **Real observability** — you can trace a single event across systems without stitching logs together
- **Consistent reliability** — retries and DLQ handling behave the same across all integrations
- **Less firefighting** — no more manual re-syncs or late-night debugging sessions

## Trade-offs (and they matter)

- **Storage overhead** — storing every event adds cost, especially at scale
- **Idempotency requirements** — replay will break things if consumers can't handle duplicates (and many systems can't)
- **Architectural shift** — this requires thinking in event flows, not sync jobs

## Conclusion

If you cannot replay what happened between your systems, you cannot recover from failure.

You can restore your database. But you cannot restore your system.

Source: https://queuey.ai/articles/backup-integration-data-event-replay/