scheduler-worker

apps/scheduler-worker is a headless Node.js process that dequeues jobs from Redis (BullMQ) and executes them. It has no HTTP server — it only consumes queues.

Overview

Attribute	Value
Type	BullMQ worker (no HTTP)
Queue backend	Redis (shared with scheduler-api)
Entry point	../scheduler-api/dist/worker.js (built from scheduler-api)
Dependencies	@nexus/platform-events (typed job payloads)

Job types

Jobs are enqueued by scheduler-api and consumed here:

Job / queue	Trigger	What happens
booking.reminder	24h and 1h before appointment	Sends reminder email/SMS via Resend
notification.send	Notification pipeline	Dispatches email/SMS/in-app notification
webhook.outbound	Business webhook config	POSTs event payload to tenant webhook URL
calendar.sync	Booking confirmed/changed	Syncs to Google Calendar or Microsoft 365
Batch operations	Admin triggers	Bulk status updates, data migrations

Data flow

sequenceDiagram
    participant API as scheduler-api
    participant Q as Redis / BullMQ
    participant W as scheduler-worker
    participant Ext as External (Resend, GCal, etc.)

    API->>Q: enqueue job (typed payload)
    W->>Q: dequeue (poll)
    W->>W: process job
    W->>Ext: send email / SMS / webhook / calendar event
    W->>Q: ack (job complete)
    Note over Q,W: On failure: BullMQ retries with backoff

Platform events

Job payloads are typed via @nexus/platform-events. Event names use dot-delimited notation (e.g. notification.sent, booking.reminder.24h). Adding a new job type requires:

1. Add the event type to packages/platform-events/
2. Enqueue it in scheduler-api at the right trigger point
3. Add a consumer handler in scheduler-worker

Retry behavior

BullMQ handles retries automatically. Failed jobs:

• Are moved to the failed queue visible in Bull Board (if enabled)
• Can be retried via admin UI or tRPC admin surface
• Failure counts are surfaced in the health dashboard