Event-Driven Architecture with RabbitMQ

Events decouple services—but at-least-once delivery means consumers must be idempotent. RabbitMQ excels when teams invest in publisher confirms, dead-letter queues, and outbox patterns.

Publisher reliability

Never fire-and-forget critical domain events:

• Use publisher confirms and retry with exponential backoff
• Pair database commits with transactional outbox rows
• Dedicated outbox poller publishes after commit succeeds
• Include eventId, schemaVersion, and occurredAt in every payload

Consumer design

@Processor('user.registered')
async handle(event: UserRegisteredEvent) {
  const processed = await this.idempotencyStore.get(event.eventId);
  if (processed) return;
  await this.welcomeEmail.enqueue(event.userId);
  await this.idempotencyStore.set(event.eventId);
}

Dead-letter handling

Exchange topology

Prefer topic exchanges with explicit routing keys per domain (user.registered, payment.captured). Fanout is for broadcast analytics, not command routing.

RabbitMQ rewards disciplined schemas and idempotent handlers—treat events as contracts, not log dumps.

Schema evolution

Version every event payload. Consumers ignore unknown fields; producers never remove fields without deprecation window. Breaking schema changes are new routing keys—not silent Friday deploys.