Integrations That Survive Outages
One business transaction runs through five outside systems. Each of them works. The trouble starts when one of them cannot be reached. This is a public live demo where you cut a line yourself and watch nothing get lost.
Every system works. The gaps between them do not.
A payment arrives and the customer never appears in the CRM. A form is submitted and no invoice is written. Nobody notices until somebody asks three weeks later. The failure is almost never inside a system, it sits in the handover between two of them.
- One call fails once, and the record is simply never written
- Retries either stop after the first try or hammer a struggling system in lockstep
- A replayed webhook books the same order a second time
- What did not go through is invisible, so nobody can act on it
- A mediator with a queue sits between the order and all five systems
- Six attempts on a jittered schedule, so a returning system is not flooded
- Exactly once at the target, held up by database constraints and a technique per system
- Whatever cannot be delivered lands in a visible backlog for a person, instead of disappearing
One order, five systems.
The scenario is deliberately ordinary: somebody buys something. Payment, CRM, invoice, notification, confirmation mail. Five separate systems, four of them owned by somebody else, and every one of them a place where a delivery can go missing.
Payment
A payment intent created with an idempotency key, so a replayed webhook cannot charge twice.
CRM
Contact, deal and line items. The email address is the natural key, so a retry patches rather than duplicates.
Invoice
An invoicing service of our own. A unique constraint on the event makes a repeat return the original invoice number.
Notification
The message carries its own marker and the channel is read back before posting, which is the weakest technique of the set and is labelled as such.
Confirmation mail
Queued only once every other delivery is done, so its arrival timestamp actually means something.
A queue, a retry schedule, and a backlog somebody can see.
One process writes the queue, so the exactly-once rules live in exactly one place. It knows nothing about the switches on the page: it sees a failed HTTP call and does what it would do in production.
Cut a line yourself.
Every system on the page carries a menu: reachable, slow, failing, unreachable. None of it is simulated. Unreachable really destroys the socket, so the caller sees a genuine connection reset, and slow holds the request eight seconds against a five second timeout. Then you watch the queue do its job.
Two things the demo says about itself out loud. The retry schedule is compressed to fit a visitor's attention span, where production would start at thirty seconds and stretch over hours. And there is one shared world, not one per visitor: a private sandbox would mean the switches were not really switching anything, which is the one property the whole page rests on.
The numbers, and where they come from.
The soak run writes its own result file and CI regenerates it on every push, so the figure on the box is not one somebody typed in once and forgot about.
Read the backlog with your own client.
An MCP server answers out of a read-only view over the same parked rows the page lists. It is handed the read-only database url and no other credential at all, so the strongest thing to say about that open port is not that it exposes no write tools, it is that it holds nothing that could write.
claude mcp add --transport http ngl https://ngl.danielsolves.ai/mcpWhat is waiting
Parked deliveries, oldest first, with a total count and an optional filter by target system.
One of them in full
A single parked delivery with its last error, plus the order and the basket behind it.
Orders taken
Every order the demo has processed, newest first, with how each system it was queued for fared. No names, no addresses.
One order
The same shape for a single order, found by the number printed on the card a visitor can read out loud.
Four required checks, then a human.
There is no staging environment, so every merge to the main branch is immediately public. That makes the gate before a deploy the interesting part of the pipeline rather than an afterthought.
Four checks, all required
Lint, types and the full test suite. A soak run in its own job. A secret scan. And the whole stack brought up from a bare checkout.
The clone really is the demo
One check does nothing but bring the stack up with no configuration at all, then asks the running MCP server to list its tools the way a client would.
Built once, pulled once
The nine images are built in CI and pushed to the registry tagged with the commit. The host builds nothing, so what serves traffic is the thing the tests ran against.
A human gate before every deploy
The deploy parks on a protected environment until it is approved by hand. What follows is one SSH call, pinned on the far side to a single command.
Tech stack.
Do records go missing between your systems?
If a payment, a form or a webhook sometimes fails to arrive somewhere and nobody finds out for weeks, that is a fixable problem with a known shape. Tell me what your chain looks like; I'll reply within 2 hours.
Start a project