GuideBeginner
Event Driven Architecture
Learn to build systems that communicate through events instead of direct calls: when an event beats a synchronous call, how a broker works, how to consume events idempotently, how to publish them reliably with the outbox pattern, and the bigger patterns they unlock — event sourcing, CQRS, sagas. You work through a single case study from start to finish: Mercado, whose checkout today is a fragile chain of synchronous calls (if `notifications` goes down, the order fails), which you'll turn into an event-driven flow where `orders` emits `OrderPlaced` and several services react in a decoupled way. Everything is simulated and executed in Python with an in-memory broker: you'll measure how at-least-once delivery produces duplicates and how an idempotent consumer neutralizes them, simulate a crash that exposes the dual-write problem and see how the outbox fixes it, rebuild an `Order`'s state by replaying its event log, and run a saga with compensation. By the end you know exactly what an event-driven system gains and what it costs compared to a synchronous one.
- 64
- lessons
- 8
- modules
- English · Spanish
- available in
- Yes
- certificate
- Free
- access
Outcomes
What you'll be able to do
- Distinguish events from commands, and understand the temporal decoupling that pub/sub enables
- Understand the broker: queue vs. topic, offsets, consumer groups, and why delivery is at-least-once (never exactly-once)
- Build idempotent consumers that deduplicate by `event_id`, and handle ordering when it isn't guaranteed
- Solve the dual-write problem with the outbox pattern: publish an event reliably in the same transaction as the data
- Apply event sourcing: store the event log as the source of truth and rebuild state via replay
- Apply CQRS: separate the write model from the read model and understand the read model's eventual consistency
- Design sagas for business transactions that span multiple services, with compensating actions when a step fails
- Convert a fragile synchronous flow into an event-driven one end to end, with idempotency, outbox, and a saga executed and measured
Before you start
What you need to bring
It's for you if...
- Backend devs with a fragile synchronous flow (one call fails and the whole process breaks) who want to decouple it
- Devs who already use a queue or message broker but don't apply idempotency or handle duplicates with judgment
- Anyone who needs to understand event sourcing, CQRS, or sagas before deciding if their system needs them
- Teams evaluating a move from synchronous calls to events who want to measure the tradeoff, not assume it
Requirements and materials
- Basic Python (the brokers and simulations in this guide run in Python, no real Kafka or RabbitMQ)
- General knowledge of databases and transactions
- No prior experience with messaging, queues, or distributed systems required
Content
The syllabus, module by module
Open any of them to see its lessons.
- 1. Module introduction: store the facts, not the result
- 2. Store the events, not the state
- 3. The `Order` as the sum of its events
- 4. Rebuilding state by replay
- 5. The log as source of truth
- 6. Snapshots
- 7. When to use event sourcing (and when it's over-engineering)
- 8. Project: convert Mercado's `Order` to event sourcing
- 1. Module introduction: separating what writes from what reads
- 2. Command and query: two operations, two models
- 3. The projection and the read model
- 4. Eventual consistency: the read model lags behind
- 5. One log, many read models
- 6. Read only from the read model (and rebuild it)
- 7. When to use CQRS (and when it's overkill)
- 8. Project: split Mercado's order flow into writing and reading
- 1. Module introduction: the transaction that crosses services
- 2. The cross-service transaction problem
- 3. Why not two-phase commit
- 4. The saga and compensating actions
- 5. Choreography versus orchestration
- 6. The lost isolation of sagas
- 7. Compensatable, pivot and retriable
- 8. Project: a saga for Mercado's checkout
- Module introduction: the return journey, with the complete system running
- 2. Modeling the order events
- 3. Publishing the order events with the outbox
- 4. Idempotent, decoupled consumers
- 5. The checkout saga with compensation
- 6. Measuring synchronous versus event-driven
- 7. The architecture decision record
- Project: make Mercado's order flow event-driven
Common questions
What people usually ask
No limit. It's a free guide: come in whenever you like, as often as you like.
No. Modules run from easier to harder, but you can jump to the one you need. Progress is saved per lesson.
Whatever is needed is listed under “What you need to bring”, above. If nothing is listed there, you can start from zero.
In the Club's WhatsApp group, and every two weeks there's a live with an instructor where questions get worked through.
Yes. It's issued automatically once you finish every lesson, with a verifiable code you can share on LinkedIn.
Start whenever you like
What students say
These reviews are from enrolled students who completed at least 50% of the course. We moderate reviews only on content grounds (spam, offensive language, personal data), never for being critical or negative.
No approved reviews yet.
Be the first to share your experience!