Sample work · AI & Automation
Fault-tolerant automation: Order, invoice, inventory, mail without double booking
A workflow from order to email was intentionally disrupted: timeouts, server errors, duplicate deliveries, and hard crashes. The hardened version does not book anything twice and does not silently lose anything.
Sample work (demo), not a client job. Built as a trial task with invented example data; the check figures below come from the automatic test run and are not polished.
What was built
- Each step with its own key so that a retry does not book anything twice
- Retries with increasing wait time; what fails permanently ends up reported in a dead-letter list
- After a crash, it continues at the correct point
Download fehlerfeste-automation-demo.zip
A step can only be executed exactly once if the counterpart accepts a key or allows reconciliation. A sent mail cannot be recalled.
How it was checked
Automatic test run on 2026-10-31, taken from the log (test data invented, figures measured):
- 40 orders, 46 deliveries (6 duplicates), 12 fault scenarios (timeout after/before execution, 5xx 1-3x), 1 permanent failure, 2x 422, 3 hard process aborts per run. Outcome: 10 duplicate invoices, inventory wrong by 15 pieces, 7 duplicate mails
Limits
What this sample does not cover, so nobody expects more:
- Exactly-once only applies to steps where the counterpart accepts an idempotency key or allows reconciliation (search by reference/key/message-ID); without both, only … remains
- Mails cannot be recalled after sending: sending is therefore the last, previously marked step; without a queryable sending protocol, a crash can occur right between sending and marking …
- The counterpart's reconciliation queries are considered reliable in the test; if the search also fails, it is retried or the event is placed in the dead-letter list instead of blindly booking again
- Real platforms have their own retry semantics (n8n: retry on fail per node, error workflow; Make: break handler/incomplete executions; Zapier: autoreplay) - the patterns here are applied there …
- Dead-letter means: cleanly stopped and reported, not repaired - partial executions (invoice present, inventory not booked) require a business decision (cancellation or subsequent booking)
- Backoff without random jitter so that it is precisely testable; with many parallel workers, jitter is required. One worker, no concurrency; multiple workers additionally need …
Something like this for your business?
Describe briefly what you need. You get a fixed price before I start; nothing happens without your yes.