Event-Driven Basics

Thinking in events, not calls

In a traditional request/response system, a service asks another service to do something and waits for an answer. In an event-driven architecture, a service instead publishes a fact about something that already happened — an event like OrderPlaced or PaymentCaptured — and other services react to it on their own schedule.

Core roles

• Producer — emits an event to a broker (Kafka, RabbitMQ, SNS/SQS) when something changes. It does not know or care who consumes it.
• Broker / event log — durably stores and routes events, decoupling producers from consumers in both space and time.
• Consumer — subscribes to events and runs its own logic: update a database, send an email, trigger a downstream workflow.

Why teams reach for it

• Loose coupling — adding a new consumer (e.g. a fraud-check service) requires zero changes to the producer.
• Resilience — if a consumer is down, events queue up and are processed when it recovers; the producer is never blocked.
• Scalability — producers and consumers scale independently, and partitioned logs allow parallel consumption.
• Extensibility — the same event stream feeds analytics, audit, search indexing, and notifications simultaneously.

Events are the foundation. The two patterns in this module — Event Sourcing and CQRS — push the idea further: one treats events as the system of record, the other separates how you write from how you read.