Use cases
Four patterns cover most of what backend teams run outside the request/response cycle. All of them use the same job and step primitives underneath — so learning one means you've effectively learned all four.
Most backends end up needing some combination of these four patterns — usually starting with background jobs for anything slow, then adding scheduling and webhook handling as the product grows. Below is what's actually included with each, not just the one-line pitch.
Offload slow work — emails, file processing, report generation — from the request/response cycle.
Example
A user uploads a video. The upload endpoint returns immediately, and a background job handles transcoding, thumbnail generation, and notifying the user when it's ready.
Nightly syncs, billing runs, and cleanup jobs that need to run on a schedule, not on a request.
Example
Every night at 2am, sync inventory counts from a supplier's API, update stock levels, and flag any SKUs that are out of sync for manual review.
Receive, verify, and process webhooks from Stripe, GitHub, or your own partners — reliably.
Example
A Stripe webhook fires on a failed payment. Nodeflux verifies the signature, retries your handler if it errors, and alerts you if it still fails after three attempts.
Multi-step ETL and data-sync jobs that need to checkpoint and resume, not rerun from scratch.
Example
A daily pipeline extracts records from three sources, transforms and dedupes them, then loads the result into a warehouse — resuming from the last successful step if one source times out.
Frequently asked questions
No. Background jobs, scheduled tasks, webhook processing, and data pipelines all use the same job and step primitives — you're not learning four different systems.
Yes. A job can be triggered by a schedule, an event, or both — for example, a sync job that runs nightly but can also be triggered manually from your admin panel.
Nodeflux is built for the long tail of background work most backend teams run — not a replacement for a dedicated big-data processing engine. If you're moving terabytes, talk to us about fit first.
Yes. A webhook-triggered job can call other jobs as part of its steps, so a single incoming event can kick off a multi-stage pipeline without you wiring up the handoff yourself.
If work happens in response to a user action, it's a background job. If it happens on a timer, it's scheduled. If it happens in response to a third party, it's a webhook. Most real systems use two or three of these together.
