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.