Background jobs, retries die je kunt verdedigen, fouten die het dashboard laat zien.
Background jobs zijn het deel van het product dat misgaat zonder dat iemand het ziet. We bouwen queues met expliciete retry-regels, idempotente handlers, dead-letter queues voor echt kapot werk, en dashboards die laten zien wat draait, wat vastzit, en wat faalde. Het ops-team ziet de waarheid; het productteam hoort niet meer via support-tickets dat er iets stuk is.
Wat we bouwen
Een queue-laag die productie aankan
Per-job timeouts, configureerbare concurrency per queue, rate-limited workers waar downstream-API's dat nodig hebben, en een nette scheiding tussen de queue-laag en de bron-van-waarheid database, zodat een volgelopen queue nooit je data corrumpeert.
Idempotente handlers als default
Elke handler is veilig om twee keer te draaien. State-changes zijn gededuped op een job-afgeleide key. Een retry-storm corrupteert de database niet; een handmatige replay tijdens incident response ook niet.
Retry-policies, geen retry-hoop
Per-job retry counts, exponential backoff met jitter, en expliciete handling voor retryable vs non-retryable errors. Een 429 van een leverancier retryt; een 400 niet. Het beleid is gedocumenteerd in de job-definitie, niet de harde weg geleerd.
Dead-letter queues die iemand leest
Jobs die hun retries uitputten landen in een DLQ met de volledige payload, error chain en timestamps. De DLQ heeft een UI, een eigenaar en een SLA. Het is niet waar jobs in stilte sterven.
Observability via error-tracking + queue-dashboard
Elke handler is geïnstrumenteerd; fouten krijgen volledige stack traces met de job-payload. Het queue-dashboard toont huidige depth per queue, lag, en recente fouten. Productie is geen black box.
Geplande jobs als code
Cron-vormig werk is gedefinieerd naast de queue, version-controlled, en zichtbaar. Geen 'wie heeft die cron op de box gezet'-verrassingen. Recurring backups, reconciliaties, en digest emails draaien allemaal via dezelfde scheduler als de rest van de queue.
Waar dit past
Je product opgeleverd al background-werk via setTimeout of onbeheerde crons en het begint te bijten.
Je hebt een queue maar geen observability in wat vastzit, en je komt er pas achter als een klant vraagt waarom zijn export niet aankwam.
Je integreert met drie leverancier-APIs, elk anders rate-limited, en de huidige code zit in één handler die throwt als één van hen traag is.
Tech stack
- TypeScript
- BullMQ
- Redis
- Postgres
- Sentry
Wil je dit voor je team?
30 minuten om vast te stellen wat je nodig hebt. Geen pitchdeck, geen verplichtingen. We zeggen je eerlijk of Stacklane past.
Plan een gesprek