Resources · Reference architecture
The design we start from when forms, payments, CRMs and schedules need to trigger work across your tools, sometimes with an AI step in the middle, without losing or doubling a record. It is a reference design, not a client system, and it keeps the same shape on n8n or in code; the queue behaviour it relies on is cited with the date we checked it.
Layer: all four, centred on Reason and Control
The problem
Point-to-point automations work until volume or failure arrives: a webhook fires twice, a CRM is down for a minute, a model call times out, and someone finds a duplicate contact or a lead that never arrived. This design treats every trigger as an event with an id, stores it first, and lets workers process it at their own pace, safe to retry and easy to replay.
Use it when several systems trigger work, volumes vary or a duplicate costs money. A single low-volume Zap that copies a form into a sheet does not need it.
Components
Form webhooks, payment and CRM events, and schedules that sweep systems without webhooks for changed records.
Verifies the signature, writes the raw event with its id and only then returns 200. No business logic lives here.
Every event as received, so a run can be traced and replayed from the original payload.
Holds jobs until a worker succeeds, with a retry limit and a dead-letter list for jobs that run out of retries.
Small steps that each do one thing (enrich, write to the CRM, notify) and check the event id before they write.
A worker that classifies, extracts or drafts; its output must pass a schema check before the next step uses it.
Which event ids have completed which writes, so a retry or replay skips work already done.
Jobs that ran out of retries, with payload, step and last error; an operator fixes the cause and replays with the same id.
Data flow
How it works
Mechanism 01
Senders retry when they do not get a quick 200, and some eventually give up. So ingress only verifies and stores before replying. The slow work happens later, from the queue, so a sender never waits on your CRM or a model.
Fewer parts, until a slow step causes a timeout, the sender retries and the work runs twice.
Mechanism 02
Queues deliver at least once, so duplicates are normal rather than rare accidents. Every write is keyed by event id plus step name, and a worker that finds the key completed skips the write. Retries and replays become safe by construction.
Fine in testing; in production the first network blip creates a duplicate contact or a double charge.
Mechanism 03
A job that runs out of retries moves to a dead-letter list with its payload, step and last error; without one, a queue deletes such messages for good. The owner sees a short, readable list and replays once the cause is fixed.
Hides the failure, piles load on a broken system and delays everything queued behind it.
Mechanism 04
n8n in queue mode already separates a main instance that receives webhooks from workers that run executions, which fits this design. Steps that need strict idempotency or heavy volume move to code workers on the same queue.
Easy to draw, hard to retry: a failure halfway forces a rerun of everything before it.
Reference diagram
Two webhooks and a nightly schedule reach an ingress that logs each event and queues it. An enrich worker and a model step feed a CRM writer that upserts with idempotency keys; jobs out of retries go to the dead-letter list, which alerts the ops owner to replay.
Diagram with 13 parts: Form webhook (source), Payment event (source), Schedule (source), Ingress endpoint (processing), Event log (system of record), Durable queue (processing), Enrich worker (processing), Model step (model), CRM writer (processing), Dead-letter list (control), Your CRM (system of record), Idempotency store (system of record), Ops owner (human).
Connections:
Platform
The event log, retries, the dead-letter list and replay.
Workers as narrow steps with idempotent writes.
Schema checks on model output, and review for anything that fails them.
Running n8n or the workers in your own accounts.
Build or buy
| Option | Fits when | The trade-off |
|---|---|---|
| Zapier or Make on their own | Low volume, few systems, and a duplicate or a missed run is an annoyance rather than a cost. | Retry and replay follow the tool’s rules, and idempotency is hard to enforce across steps. |
| n8n on this reference design | Several sources, an AI step, data kept on your server, and a team that likes visual workflows. | You run n8n, or pay for n8n Cloud, and keep its queue, workers and error workflow healthy. |
| Code workers on a managed queue | High volume, strict ordering per record, or writes where a duplicate is expensive. | Changes need a developer, and the run log and replay page have to be built. |
Rollout
Week 1
List every trigger, how its sender retries, and what a duplicate or a miss would cost.
Weeks 1–2
Store-then-acknowledge endpoints and the queue with retry limits and a dead-letter list.
Weeks 2–4
Idempotent workers, the schema-checked model step, and tests that replay real payloads twice.
Weeks 4–5
The new pipeline runs beside the old automation, and results are compared before the switch.
After launch
A named owner, alerts and a short weekly look at what failed and why.
Failure modes
Running cost
Defaults
Limits
Configuration
pipeline: lead-intake
sources:
- webhook: site-form # signature: hmac-sha256
- schedule: crm-changes # nightly, from the last change cursor
ingress:
store_then_ack: true
queue:
key: "{event_id}:{step}"
max_retries: 5
backoff: exponential-with-jitter
dead_letter: lead-intake-dlq
workers:
- enrich: { reads: [company-lookup] }
- classify: { model: true, output_schema: lead.v2 }
- crm_upsert: { idempotent: true }
alerts:
dead_letter_over: 0
owner: ops-ownerFAQ
When several systems trigger it, volumes jump, a step is slow (a model call, a busy API) or a duplicate costs money. If one form copies into one sheet and nobody minds a rare miss, a direct flow is fine and cheaper to keep.
They wait. Each event is already stored and queued, so the CRM worker retries with backoff; if the outage outlasts the retries, jobs park on the dead-letter list and are replayed once the CRM is back.
Yes, as one worker with a narrow job: classify, extract or draft. Its output must pass a schema check before the next step uses it, it never writes to a system directly, and anything that fails goes to a person with the raw output attached.
Yes. n8n’s queue mode already separates the instance that receives webhooks from the workers that run executions. We add the event log, idempotency keys and a dead-letter list around it, and move only the strictest steps to code.
Replay the original event with its original id. Each write checks the idempotency store, so finished steps are skipped and only the failed ones run again. Replaying a fresh copy with a new id is what creates duplicates.
One named person on your operations side, with a backup. They get an alert when the list grows, fix the cause or ask us, and replay. A dead-letter list nobody owns is a slower way of losing data.
Next step
Book a free 30-minute strategy call. Bring one process you want to automate and we will talk through scope, integrations and a sensible first step.
Free 30-minute call · no commitment