Architecture
Event Driven
Components communicate by emitting events to a broker instead of calling each other directly, so producers and consumers stay decoupled and new consumers can subscribe without touching the source. It excels at asynchronous, reactive workflows and audit trails. The cost is harder debugging, eventual consistency, and reasoning about ordering and replay.
Purpose
In an event-driven architecture, components announce facts — OrderPlaced, UserSignedUp — to a broker instead of calling each other directly. Producers do not know who listens; new consumers subscribe without touching the source. It exists to decouple systems in time and in knowledge.
When to Use It
Reactive workflows that fan out — an order triggering email, inventory, analytics and fraud checks in parallel — plus audit trails, integrations between teams, and feeding data platforms. Event sourcing extends the idea by making the event log the source of truth itself.
Trade-offs
The flow of causality becomes invisible: no single stack trace shows what happened, consistency is eventual, and you must reason about ordering, duplicates and replay. Schema evolution of events becomes a contract-management problem of its own.
Implementation
Publish events through a broker (Kafka, RabbitMQ, SNS/SQS); name them as past-tense facts and version their schemas. Make consumers idempotent, plan dead-letter handling, and add correlation IDs so a business flow can be traced across hops. Keep events lean — a fact plus identifiers, not the whole world.