Decouples components
The producer can change without requiring every consumer to deploy at the same time.
MODULE 07 · SYSTEM ARCHITECTURE
Event-driven
Event-driven architecture lets components react to events instead of relying only on direct request-response calls.
01
What is it?
Event-driven architecture is a way to organize a system around things that happen. One component records an event, and other components decide whether they need to react to it.
An event is a fact about the past, such as OrderPlaced, PaymentConfirmed, or FileUploaded. The producer publishes that fact without needing to know every consumer that may use it later.
Simple definition:
Publish what happened, then let interested components respond.
02
Think of it like...
Think of a public train station announcement. The station announces that a train has arrived. Passengers, cleaners, and staff can each take the action they need; the announcement does not call each person one by one.
Something happens
Event is published
Interested components react
The useful separation: the producer announces a fact, while consumers own their own responses. A new consumer can subscribe without changing the original producer.
03
What does it do?
It changes how work is coordinated. Instead of one service knowing every next step, events create a shared handoff point that many components can observe.
Supports fan-out
One event can trigger inventory, notifications, analytics, and fulfillment independently.
Absorbs bursts
A broker or queue can hold work while consumers catch up with a traffic spike.
Enables async work
Slow follow-up work can continue after the user receives an initial acknowledgement.
Adds flexibility
Teams can add a new reaction, such as a loyalty update, without rewriting checkout.
Creates trade-offs
Distributed flows need monitoring, retry rules, duplicate handling, and clearer status design.
PM perspective: event-driven design can make a product more resilient and extensible, but it does not remove complexity. Ask who owns each reaction, what the user sees while work is in progress, and how failures are recovered.
04
Where is it used?
Use event-driven patterns when several parts of a product need to react to the same business fact, or when the next step does not need to block the current interaction.
Online orders
An order event can start inventory reservation, payment checks, fulfillment, and customer updates.
Ride-hailing
Trip status events can update the rider, driver, pricing, maps, and support systems.
Fraud detection
A transaction event can be scored by a risk system without putting every rule inside checkout.
SaaS notifications
A workspace change can trigger email, push, audit-log, and webhook consumers.
Media pipelines
An upload event can start scanning, resizing, transcription, and search indexing.
Data products
Business events can feed analytics and reporting without coupling dashboards to the transaction path.
05
Example
An online retailer confirms an order
A customer clicks “Place order.” The order service validates the request and records the order, then publishes OrderPlaced. The inventory service reserves stock, the payment service authorizes payment, the notification service sends confirmation, and analytics records the business event.
Customer places order
OrderPlaced event
Inventory · Payment · Notifications · Analytics
Order status updates
Product decision: the customer can receive a fast “order received” acknowledgement, but the product must make later states visible: payment pending, stock unavailable, confirmed, cancelled, or retrying. Event-driven architecture is only a good experience when the state changes are understandable.
06
How it connects
A typical event-driven flow has a producer, an event broker or queue, and one or more consumers. A consumer may update its own data or publish another event for the next part of the workflow.
Producer
publishes a fact
publishes a fact
Broker or event bus
routes and retains it
routes and retains it
Consumers
react independently
react independently
Important connection: event-driven and asynchronous often appear together, but they are not synonyms. A system can publish an event synchronously, and asynchronous work can be coordinated without a broad event-driven architecture.
07
Do Not Confuse
Event-driven vs synchronous
Event-driven describes how components coordinate around facts. Synchronous describes a caller waiting for a response.
Event vs command
An event says something already happened. A command asks a specific component to do something.
Event-driven vs asynchronous
Event-driven is an architecture style. Asynchronous is a timing and waiting model. They often overlap, but one does not guarantee the other.
Queue vs event bus
A queue commonly gives a message to one consumer. An event bus commonly lets multiple subscribers receive the same event.
PM check: do not promise “real time” just because a product uses events. Confirm the expected delay, ordering, duplicate behavior, and user-visible recovery path.
09
What to Remember
Event-driven architecture lets a component announce a business fact once, then lets independent consumers react in their own way.
Its strengths are decoupling, fan-out, resilience, and extensibility. Its costs are eventual consistency, distributed debugging, duplicate delivery, ordering questions, and more product-visible states.
PM perspective: define the event, the owner of each reaction, the expected delay, and the user experience for pending, success, failure, retry, and cancellation.
Business fact→Event→Independent reactions→Visible outcome