Skip to main content

Module 3: Event-Driven Architecture: Worked Examples

Example 1: Publish Without a Dual Write​

Problem. An order transaction commits, but publishing OrderAccepted fails.

Wrong attempt. Retry publishing from application memory. A process crash loses the event; publishing first can emit an event for a rolled-back order.

Correct reasoning. Write the order and outbox row in one local transaction. A relay publishes with retries; consumers deduplicate by event identity. Monitor outbox age and relay failures.

Example 2: Design an Event as a Fact​

UpdateCustomer is a command and leaks intent. CustomerAddressChanged is an immutable past-tense fact with event ID, aggregate ID, schema version, occurred time, producer, and the minimal stable business data consumers need. Avoid copying the producer’s whole database row.

Example 3: Repair a Poison Message​

Bound retries, distinguish transient from permanent failure, preserve the failed payload and metadata in a quarantine/dead-letter path, alert on age/rate, and provide tested replay after code or data repair. “Send to DLQ” without ownership and replay is deferred data loss.

Completion Standard​

  • Prove atomic state-and-event handoff.
  • Demonstrate duplicate and out-of-order handling.
  • Operate a poison-message repair and replay workflow.