Background jobs, retries die je kunt verdedigen, fouten die het dashboard surfacet.
Background jobs zijn het deel van het product dat misgaat op manieren die niemand opmerkt. We bouwen queues met expliciete retry-policies, idempotente handlers, dead-letter queues voor echt kapot werk, en dashboards die surfacen wat draait, wat vastzit, en wat faalde. Het ops-team ziet de waarheid; het product-team komt niet langer via support-tickets achter issues.
Wat we bouwen
BullMQ op Redis voor de queue-tier
Getypte job-payloads in TypeScript, per-job timeouts, configureerbare concurrency per queue, en rate-limited workers waar downstream-APIs het nodig hebben. Redis is de queue; Postgres is de waarheid, we halen ze niet door elkaar.
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 Sentry + queue-dashboard
Elke handler is gewrapt in een Sentry-span; fouten krijgen volledige stack traces met de job-payload. Het BullMQ-board toont huidige depth per queue, lag, en recent 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 leeft 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 met een oprichter of ervaren ontwikkelaar. We bepalen wat je nodig hebt en zeggen je eerlijk of Stacklane past.
Plan een gesprekVerwante capabilities