Many teams end up gluing their app to a background job queue through n8n webhooks, and then discover all the sharp edges: duplicate callbacks, mismatched job states, retries that corrupt data, and workflows that quietly stall under load.
This post walks through a pattern for wiring a custom job queue into n8n using webhook callbacks, with a focus on idempotency, explicit job state transitions, and failure recovery rather than “happy path” demos.
Curious how others are handling this in production:
- How do you design your callback contracts and job state machine?
- What patterns have worked (or failed) for idempotent callbacks and retries?
- Any war stories from running webhook-heavy n8n (or similar) setups at scale?
Many teams end up gluing their app to a background job queue through n8n webhooks, and then discover all the sharp edges: duplicate callbacks, mismatched job states, retries that corrupt data, and workflows that quietly stall under load.
This post walks through a pattern for wiring a custom job queue into n8n using webhook callbacks, with a focus on idempotency, explicit job state transitions, and failure recovery rather than “happy path” demos.
Curious how others are handling this in production: - How do you design your callback contracts and job state machine? - What patterns have worked (or failed) for idempotent callbacks and retries? - Any war stories from running webhook-heavy n8n (or similar) setups at scale?