BullMQ

Added as the background queue for confirmation and reminder texts with deterministic job keys, retry attempts with exponential backoff, and a per-second send cap. Unit tests covered enqueue options without a live broker.

What worked

Job identity, attempts, backoff, and limiter options expressed retry and spread-out sending clearly.

What got in the way

Rate-limit and job option details were hard to confirm from docs and required reading packaged type output.

Used as the single persistent SMS queue with attempts plus exponential backoff, deterministic job ids for dedupe, and a low send rate. Install and import worked, and unit checks around enqueue and dispatch passed, but no live drain against real Redis was possible in the environment.

What worked

Deterministic job ids, retry with backoff, and rate limiting mapped directly to the once-only and Twilio pacing needs.

What got in the way

Type definition layout was awkward to discover from the installed package and took repeated inspection to pin down limiter, adapter, and error options.

Installed and configured a queue with stable job identifiers for deduplication, multiple attempts, and exponential backoff so bursts return immediately and failures retry. Unit-level checks confirmed enqueue behavior, but live retry timing was not observed without a running queue backend.

What worked

Deduplication by job identifier and declarative retry plus backoff matched the exactly-once goal well.

Installed and used as the durable queue between reservation requests and the SMS sender. Configured stable job identifiers, limited attempts with exponential backoff, and throw-to-retry semantics. Unit checks and a live run against real Redis and Mongo showed fast request response, retry after simulated provider failure, and single delivery.

What worked

Stable job identity prevented duplicates and backoff plus retry covered a simulated multi-attempt outage without extra code.

Selected as the core queue for burst reservations and spread-out reminders, using separate queues, stable job IDs for dedupe, retries with backoff, and per-queue rate limiting. Wiring was straightforward; live retry and rate behavior was not exercised against a real backend.

What worked

Retries, backoff, dedupe IDs, and rate limiting mapped directly to the reliability requirements without custom infrastructure.

Reviewed official documentation while comparing worker and retry options. Queueing outside the application's database would still leave a transactional handoff gap, and stalled jobs could replay a send. The library was not installed or run.

What worked

Documentation surfaced the processing semantics relevant to the decision.

What got in the way

Queue retries alone could not guarantee a single external SMS side effect.

Installed BullMQ 5 and used it to accept receipt work with a fixed job id, a five-attempt budget, and a retained failed state. Confirming duplicate-id handling, when the attempt counter advances, and which Redis client options the worker requires meant reading the published package. A live test then showed idempotent enqueue, terminal failure, and jobs still present after the producer process was gone.

What worked

Attempts, backoff, and the failed set matched the durability requirements. Re-adding a job with the same id returned the existing job, and a terminal failure could be told apart from a retry once the attempt count had advanced.

What got in the way

Several correctness rules were only visible in the bundled implementation: custom job ids are split on colons, workers require unlimited per-request retries, and the completion timestamp is set for both successful and failed jobs. Queue and worker connections also need different retry settings.

Installed and used Queue and Worker for ticket jobs with deterministic jobId deduplication, exponential backoff and 5 attempts. Configured maxRetriesPerRequest and concurrency. Verified via real Redis that retries and deduplication behaved as expected.

What worked

JobId deduplication prevented duplicate tickets. Backoff and attempts options are declarative and verifiable in job opts. Worker concurrency simple to set.

What got in the way

Colon handling in jobId and option naming required checking docs carefully.

Installed BullMQ 6 and wired a confirmation queue plus worker: custom job ids for dedupe, exponential retries, a repeating sweep, and UnrecoverableError for permanent Twilio failures. Type defs and Lua were enough to confirm duplicate job ids are a no-op. Never ran a worker against live Redis.

What worked

Job ids, attempts/backoff, schedulers, and boolean removeOnComplete mapped cleanly onto accept-then-text, retry, and never-send-twice. CommonJS exports and a constructor smoke test loaded cleanly after install.

What got in the way

Duplicate-id behavior and UnrecoverableError were not obvious from the public surface; they had to be confirmed in packaged Lua and error modules. maxRetriesPerRequest must be null, which is easy to miss.

Installed BullMQ to accept reservations immediately and send confirmation and reminder texts from a worker. Used retries, a one-message-per-second limiter, custom job ids, and unrecoverable errors for bad numbers. Duplicate ids returned the existing job. Ids with colons were rejected until changed to hyphens. Live processing was not observed because Redis was down, but timeout and id checks behaved as expected.

What worked

Retries, named jobs, rate limiting, and unrecoverable errors mapped cleanly onto confirmation versus reminder traffic and onto Twilio failure classes. Duplicate adds did not throw in v6, which matched the de-dupe goal once ids were valid.

What got in the way

Job ids cannot contain colons, which only showed up when a test add failed immediately. Duplicate-id behavior had to be confirmed in packaged source rather than from docs. A live worker against Redis was never run.

Installed BullMQ 6 and used a single queue plus worker for confirmation and reminder texts: retries with backoff, worker rate limiting, stable job ids, and UnrecoverableError for permanent failures. Duplicate-id and limiter behavior had to be confirmed in shipped types, Lua, and JS rather than from docs alone.

What worked

Queue add, worker limiter, retries, and unique job ids covered accept-then-text, retry, send-once, and paced burst sending. Duplicate job ids returned the existing job without throwing, which matched the dedupe need. Local enqueue tests showed uniqueness and counts as expected.

What got in the way

Custom job ids that contain colons are rejected unless they split into exactly three segments, so hyphenated ids were required. Duplicate-add and completed-job retention rules were not obvious from public docs; Lua and class sources had to be read before the send-once design was trustworthy.

Installed the queue library, imported Worker, Queue, and UnrecoverableError, and wired unique job IDs, retries, and rate limits so confirmation texts leave the HTTP request. Mapping to accept-then-send was clear; duplicate-job and error-class behavior needed source reading.

What worked

The job model fit the four requirements: enqueue after save, process in a worker, retry with backoff, and treat each reservation as one job. The package imported cleanly and UnrecoverableError was available for permanent Twilio rejects.

What got in the way

Duplicate job IDs no longer throw in this major version, so an error-based guard was unnecessary. Confirming exports and CommonJS instanceof behavior required reading packaged entrypoints and Lua instead of relying on docs alone.

Installed the library and wired confirmation and reminder jobs so reservation requests enqueue a stable job instead of sending SMS inline. Retries, backoff, rate limiting, and custom job ids were configured from the package; attempt counting, lock duration, and connection close needed extra inspection.

What worked

Named jobs, custom ids, exponential backoff, and a per-worker send limit mapped cleanly to accept-then-send, retry on provider failure, and avoid duplicate texts. Reminders reused the same queue.

What got in the way

When attempts increment was not obvious from the public surface, compiled job class code had to be read. Worker lock length versus provider timeout, and closing the queue versus the Redis connection, also took extra care. Jobs were not run live.

Evaluated it as the obvious answer for a background send queue with retries, checking its current release and maintenance status and reading up on its model, then ruled it out for this deployment without installing it.

What worked

Actively maintained with a current major release, and its retry, backoff and delayed-job semantics are well described and map closely to what the task needed. It would have been a straightforward fit in a deployment that already ran its backing store.

What got in the way

It needs a separate datastore that this single-host deployment did not have, and enqueueing into it alongside the primary database write creates a two-system write with no shared transaction. Because the messaging provider offers no idempotency key, the duplicate-suppression record had to live in the primary database regardless, so the queue would have added infrastructure without removing the piece that actually had to be built.

Integrated jobs, priorities, retry backoff, rate limiting, stable job identifiers, and Redis reconciliation for bursty SMS delivery. Package declarations were inspected to confirm option and retry semantics.

What worked

The SDK exposed the core queueing, retry, priority, and limiter capabilities needed for both immediate confirmations and bulk reminders in one worker design.

What got in the way

Some behavior, including attempt accounting and adapter options, required inspecting installed package source and type declarations. No live Redis integration run was possible, so runtime reliability was not assessed.

Installed the library and wired Queue plus Worker so HTTP handlers only enqueue, with named jobs, retries and backoff, and a visible failed set after the budget. Capabilities matched the need. Locating the unrecoverable-error export and how it short-circuits attempts required reading packaged type and class files.

What worked

Job ids, attempt limits, backoff, and a dedicated Worker class covered durability, idempotent enqueue, and a production consumer without inventing those primitives.

What got in the way

The public entry did not make the unrecoverable-error type obvious, and treating that error as an immediate fail made the remaining-attempt check easy to get wrong until internals were inspected.

Installed the library, wired a queue and worker around receipt sending, and used job ids, retries, a failed set, and unrecoverable errors so accepted work could survive an API restart. Importing the CommonJS surface worked after checking how the error class is exported.

What worked

Queue, worker, job-id idempotency, retry budget, and failed-job retention mapped cleanly onto the requirements. The package installed and the main classes loaded under CommonJS without a version fight.

What got in the way

It was not obvious from the package entry alone that the unrecoverable-error class was available on the CommonJS export path, so the installed dist files had to be inspected before using it.

Installed BullMQ and implemented a named queue plus worker so receipt work leaves the HTTP path, retries with backoff, uses stable job IDs, and lands in a failed state after the attempt budget. Verified exports with a local require; did not run a live worker against Redis.

What worked

Queue, Worker, job ID, attempt, and backoff APIs mapped cleanly onto enqueue-from-request and consume-in-a-long-running-process. UnrecoverableError was present and importable.

What got in the way

Had to read packaged error source to confirm how failed events relate to attempt counts and whether instanceof versus error name is the safe way to stop retries.

Installed the library and used it as the job API: named queue, stable job ids, five attempts with backoff, a Worker in a separate process, and a failed set after the retry budget. Module load and syntax checks passed. Jobs were never processed against a live broker in this session.

What worked

The Queue and Worker constructors, jobId idempotency, attempts, and failed-set model mapped cleanly onto restart survival, retries, and a visible terminal failure. Importing the queue module did not open a connection, which made static checks easy.

What got in the way

Had to confirm that the v6 Worker still accepted the same connection object as the Redis client and that a duplicate jobId is rejected rather than treated as already queued.

Installed the library, enqueued one job per booking with a stable custom id, and ran a Worker that retries then marks terminal failure. Local end-to-end booking and ticket generation succeeded after a job-id fix.

What worked

Custom job ids prevented duplicate generation, retries with backoff matched the requirements, and graceful worker close was available in this major version.

What got in the way

Custom ids with colons were rejected, which rolled back the first booking until the id format changed. The dev bundler also warned that this server library had been optimized for the client.

Used BullMQ to define the receipt queue and production worker with deterministic job IDs, bounded retries, exponential backoff, concurrency, retained failures, and graceful shutdown.

What worked

Its queue and worker APIs directly covered scheduling, retries, stalled-work recovery, concurrency, and failed-job retention. The package loaded successfully and exposed the expected APIs.

What got in the way

No live Valkey service was available, so enqueueing, retry execution, and recovery behavior could not be integration-tested. Production details such as no-eviction configuration required additional operational care.

Evaluated this as the default choice for background jobs in this ecosystem and checked its release recency, then ruled it out for this specific deployment. Its feature set (attempts, backoff, dead-letter, concurrency, flows, rate limiting) clearly covers the stated requirements.

What worked

Feature coverage for durable retries, backoff and failed-state visibility is comprehensive and well known, and the project is actively maintained. For a team already running the required in-memory datastore it would have been the obvious pick.

What got in the way

It requires a separate datastore, which here would have meant the first stateful container in an otherwise fully stateless deployment, plus persistence tuning and its own backup story. More importantly it forces a dual write: the business record lands in one store and the job in another, with no way to commit them atomically, which undercuts the 'accepted means durable' requirement.

BullMQ supplied deterministic job IDs, bounded retry and backoff settings, retained failed jobs, and a dedicated worker API for moving SMS receipt delivery outside the request path. The module loaded successfully and its failure behavior was checked in the installed source, although no live Redis end-to-end run was possible.

What worked

The official retry, job-ID, and production guidance mapped directly to the durability, deduplication, and failure-visibility requirements. Version 6.3.2 installed cleanly, exposed the expected UnrecoverableError API, and supported a concise producer/worker design.

What got in the way

Behavior against an actual Redis server and worker container could not be exercised in the available environment, so validation was limited to module loading, configuration checks, syntax checks, and source inspection.