7 Event-Driven Architecture (EDA):Temporal Decoupling and Asynchronous Communication
This chapter covers
- Breaking the "Temporal Coupling" that makes distributed systems fragile.
- Distinguishing between a "Message" (Command) and an "Event" (Fact).
- Implementing the Publish-Subscribe pattern to decouple Senders from Receivers.
- Designing for "Eventual Consistency" (and accepting that the world isn't instant).
- Managing the complexity of "The Dork Side": The Apollo 13 Event Logs.
7.1 Introduction
In Chapter 6, we learned how to build a clean API. We created a Contract and a Controller to talk to the world. But in doing so, we walked right into a trap: The Dependency Chain. If your Order API calls the Inventory API, which calls the Payment API, which calls the Shipping API, you have created a distributed monolith. If the Shipping API goes down, the user cannot make a purchase, even if the inventory is full and the credit card is valid.
This is called Temporal Coupling. In a synchronous system, everything must happen now, or nothing happens at all. And this is exactly what makes it brittle, slow, and dangerous.
DEFINITION
Temporal Coupling occurs when a system’s components are dependent on time to function correctly. In a distributed architecture, this means the sender and the receiver must both be online, available, and responsive at the exact same moment for a transaction to succeed. If one side is busy, slow, or offline, the entire process fails immediately.