Event Driven Architecture Part 2: What happens when reality intervenes?

Event-Driven Architecture: From Communication to Reality (3-Part Workshop Series)

Are you a software engineer who enjoys digging into new ideas, practices, and patterns that strengthen your craft? Join us for the next OKTech Study Session, a gathering for engineers who don’t just code, but want to understand the why and how behind solid software design.

Session Summary: Event-Driven Architecture (EDA) promises loose coupling, scalability, and flexibility. In practice, it also introduces new kinds of complexity, subtle failure modes, and long-term maintenance challenges. In this three-part workshop series, we’ll explore EDA from first principles to real-world operation. The focus is on architectural decisions, trade-offs, and consequences, not on tools or frameworks.

Part 1 – How do event systems communicate? (done)
Starting with the fundamentals of communication in distributed systems:

• Synchronous vs asynchronous communication
• Events vs commands (and why the distinction matters)
• Pub/Sub, Point-to-Point, Request-Reply, and Streaming patterns

Goal: Build a clear mental model of communication styles and understand how each choice affects the system.

Part 2 – What happens when things go wrong? (current)
Because in distributed systems, failure is given:

• Poison messages and failing consumers
• Idempotency and duplicate delivery
• Out-of-order events
• Delivery guarantees

Goal: Learn how to design event-driven systems that assume failure and remain reliable when unexpected things happen.

Part 3 – How to maintain an EDA?
Once the system is running, the real challenges begin:

• Monitoring and correlating event flows
• Event versioning and documentation
• Testing event communication

Goal: Understand how to keep an event-driven system observable, evolvable, and maintainable over time.

How do we work?

• Small group to encourage discussion and participation
• Concept- and practice-focused, not tool-specific
• Interactive discussions and exercises
• The sessions build on each other, so attending all three is strongly recommended

Who is it for?

• Software engineers with 2–3+ years of professional experience
• Developers working on backend or distributed systems
• Engineers who have used events before, or expect to work with them soon
• People who want to reason about architecture, not just apply patterns by name

You don’t need to be an EDA expert, but some hands-on software engineering experience is expected.