Event-Driven Systems Architect — Build Responsive Decoupled

Semantics: OrderCreated is a fact owned by the order service after the order is committed. Notification is a downstream action, not proof that the email was delivered.

Transactional handoff: If the database supports it, write the order and an outbox record in one transaction. A relay publishes the outbox record and tracks publication. Exact transaction and relay behavior require engine-specific validation. Avoid an unprotected database-plus-broker dual write.

Contract proposal: event_id, event_type, schema_version, occurred_at and order_id, with only necessary notification data. Values and schema constraints must be agreed; no actual payload invented.

Consumer behavior: Assume duplicates may occur. Use a durable inbox/idempotency record and a controlled notification state keyed by the relevant business action. Acknowledge only after durable processing under the chosen broker semantics.

External side-effect caveat: If the email provider times out after accepting a send, outcome may be uncertain. Provider idempotency and reconciliation must be verified; a local deduplication record alone does not guarantee exactly-once email.

Failure handling: Bounded retries with backoff for transient errors. Poison messages go to an owned dead-letter process with diagnosis, repair and safe replay. Avoid retry storms.

Observability: Correlate event, order and notification state; track relay backlog, consumer lag, failures and uncertain outcomes using actual telemetry.

Validation: Duplicate messages, relay crash, consumer crash, provider timeout, incompatible schema and replay. Confirm invariants on representative infrastructure.

Status: Architecture proposal only. No broker configured, event sent, email delivered or test executed.