Workflow Automation_Business Operations PlatformEmail queue engineering

Replacing form-triggered email code with a durable BullMQ workflow_

Parallaxis separated submission from delivery: the application stores the event, resolves the employee through the database, enqueues a typed job, and lets workers retry only the failed step. The business application can

BullMQ email routing
BullMQ and Redis workers
Employee-ID recipient resolution

Challenge_

Form submissions triggered important employee notifications, but direct SMTP calls made the user wait and lost work when the mail provider or employee lookup failed.

Approach_

Parallaxis separated submission from delivery: the application stores the event, resolves the employee through the database, enqueues a typed job, and lets workers retry only the failed step.

Outcome_

The business application can respond quickly while operations gains retry history, dead-letter handling, template versions, and an auditable record of who should have received each message.

Overview

Form submissions triggered important employee notifications, but direct SMTP calls made the user wait and lost work when the mail provider or employee lookup failed.

Parallaxis separated submission from delivery: the application stores the event, resolves the employee through the database, enqueues a typed job, and lets workers retry only the failed step.

The engineering decision

Email is an operational side effect. Idempotency keys prevent duplicates, database state remains the source of truth, and retries use bounded backoff rather than blind repetition.

How the system works

The implementation separates intake, validation, state changes, side effects, and reporting. That separation makes failures visible and allows one layer to change without rewriting the entire workflow.

Operational users see explicit statuses and exceptions; technical teams retain identifiers, timestamps, versions, and logs needed to reproduce a result.

Outcome