Node.js Event-Driven Architecture with TypeScript

What this prompt does

This prompt asks the AI to design a full event-driven architecture for a [domain] application in Node.js and TypeScript, where the contracts come before the wiring. It produces typed domain event definitions for your [events], an event bus built on a [broker], a handler registry with automatic discovery, a saga to coordinate the [saga_flow] workflow, idempotency via event deduplication, and a dead-letter queue with [max_retries] retries and exponential backoff. It also covers event sourcing for the [sourced_aggregate] aggregate, schema versioning, and correlation-ID tracing across events.

The structure works because it forces the hardest decisions first. By naming your real [events] and the [broker] you intend to use, the AI grounds the design in your stack instead of a generic example. The saga and dead-letter sections are where event systems usually rot — a single failed event can silently break a multi-step flow — so making them explicit gives you idempotent, recoverable handlers rather than fire-and-forget calls that lose data under load.

When to use it

• You are starting a new Node.js backend where order, payment, or fulfillment steps must coordinate reliably.
• You want typed events shared across services so a payload change is a compile error, not a runtime surprise.
• An existing system loses events when one handler fails and you need dead-letter and retry semantics.
• You are introducing a saga to replace a tangle of nested await calls across services.
• You need event sourcing for an aggregate where the full history matters, such as Order.
• You want correlation IDs threaded through events before debugging distributed flows becomes painful.

Example output

Expect a structured design document with TypeScript code blocks: typed event interfaces, an event-bus class wired to your [broker], a handler-registry module, a saga/orchestrator implementation for [saga_flow], a dead-letter handler with backoff, and an event-sourced [sourced_aggregate] with apply/replay methods. It reads as a blueprint plus runnable snippets, not a single monolithic file.

Pro tips

• Set [events] to the exact event names in your domain (for example OrderPlaced, PaymentProcessed) so the generated types match what your code will actually publish.
• Pick [broker] deliberately — Redis Streams via BullMQ behaves differently from Kafka, and the AI tailors the bus and consumer code to it.
• Keep [max_retries] realistic; high retry counts on a non-idempotent handler just amplify damage, so confirm idempotency first.
• Describe [saga_flow] as ordered steps (validate → reserve → charge → confirm) so the orchestrator and compensating actions line up with reality.
• Choose [sourced_aggregate] carefully — event source only the aggregate whose history you truly need to replay, not every entity.
• Iterate by asking it to add compensating transactions or to show how a poisoned event moves to the dead-letter queue and back.