Event-driven architecture

/02 About

Producers publish events to a broker; consumers react independently, with a schema registry and a dead-letter queue.

Components communicate by publishing facts that happened rather than calling each other. Consumers subscribe to what they need and can be added without changing the producer. When to use: workflows that span several systems, integrations that must not block each other, fan-out to many consumers, and audit trails of what happened. Trade-offs: loose coupling and resilience to slow or failing consumers, at the cost of eventual consistency, harder end-to-end tracing and the need to version event schemas carefully. Plan for duplicates and out-of-order delivery: consumers must be idempotent.

Published by Lattix · 9 elements · 8 relationships · validated on publish