event-driven-architecture

Event-Driven Architecture

When to Activate

Activate when:

• Designing or implementing message-based communication between services
• Building systems that require asynchronous processing
• Decoupling producers from consumers in distributed systems
• Implementing event sourcing or audit trails
• Setting up webhooks, message queues, or pub/sub patterns

Steps

1. Identify Event Boundaries

Define what constitutes an "event" in your system:

• Events are facts about something that happened (past tense: OrderPlaced, PaymentProcessed)
• Commands are requests for an action (present tense: PlaceOrder, ProcessPayment)
• Events should be immutable once emitted

2. Choose the Right Messaging Pattern

Pattern	Use Case	Examples
Pub/Sub	One-to-many notification	Notifications, audit logs
Message Queue	Point-to-point processing	Order processing, email sending
Event Streaming	Durable, replayable event log	Event sourcing, analytics
Webhooks	External system integration	HTTP callbacks

3. Design Event Schema

interface Event<T> {
  id: string;           // Unique event identifier (UUID)
  type: string;         // Event type (e.g., "ORDER_PLACED")
  version: string;      // Schema version for evolution
  timestamp: string;    // ISO 8601 timestamp
  source: string;       // Origin service name
  data: T;             // Event payload
  metadata?: Record<string, unknown>;  // Optional tracing/correlation
}

4. Handle Eventual Consistency

• Design consumers to be idempotent (safe to process twice)
• Use correlation IDs to track event chains
• Implement dead letter queues for failed processing
• Set retry policies with exponential backoff

5. Ensure Durability

• Use persistent message storage (not in-memory)
• Acknowledge messages only after successful processing
• Implement at-least-once delivery semantics

Examples

TypeScript Event Emitter