🔒 The Power of Commands in Event-Driven Architectures

Directing the Flow, Orchestrating Actions

Welcome to The Engineer Banker, a weekly newsletter dedicated to organizing and delivering insightful technical content on the payments domain, making it easy for you to follow and learn at your own pace

Learn payments with The Engineer Banker

Want free access to paid posts like this one?

Invite your friends to read The Engineer Banker

---

Summary

This comprehensive article from The Engineer Banker delves into the nuances of Event-Driven Architectures, focusing on the key distinctions between commands, queries, and events in a payments system context. It explores how large-scale, real-world systems often employ a hybrid approach to cater to different needs, utilizing either a Fan-Out or Competing Consumers pattern based on propagation expectations. The article also discusses the intricacies of a payments automation engine, emphasizing how commands and events function within this specialized component of a payments infrastructure. Finally, it explores the necessity of temporal coupling between components and how to guide the choice between synchronous HTTP requests and asynchronous commands.

---

Event-driven architectures (EDAs) have become pivotal in modern software systems, offering dynamic, responsive, and scalable solutions for complex applications. Within this paradigm, the distinction between commands and events is fundamental, and understanding their semantics is crucial for effective design and implementation.

In our initial exploration of Event-Driven Architectures, we delved into the details of events. If you haven't caught up on that, I'd recommend giving it a read. Today, we'll dive deeper into commands and highlight the distinctions between commands and events.

Event driven architectures in payments

Event driven architectures in payments 2: Compatibility

Commands, queries and events

Before we go any further, consider that there are three distinct ways that programs can interact over a network: commands, events, and queries.

• Commands are actions, requests for something to happen. They may include a response.

• Events are both a fact and a trigger. Never include a response.

• Queries are a request to look something up. Unlike events or commands, queries are free of side effects. Always include a response.

In the request-driven approach, components are in a constant dialogue, making specific requests for information or actions whenever a need arises. One component, recognizing that it needs something—be it data or a particular action to be taken—actively sends out a request to another component that can fulfill this need. This form of collaboration is proactive and often synchronous, as one component waits for the response from another.

Conversely, in the event-driven model, also known as Event Collaboration, the dynamics of interaction are fundamentally different. Components in this model do not explicitly request what they need. Instead, they emit events whenever a change in their state occurs. These events serve as signals or notifications to the rest of the system. Other components are designed to listen for these specific events and react accordingly, be it by updating their own state, executing a particular function, or triggering additional events in turn.

The key difference lies in how components consider their relationships with each other. In the request-driven approach, the focus is on direct and immediate need—'I need this, so I'll ask for it now.' In contrast, the event-driven approach engenders a more decentralized and reactive form of interaction. Components in this architecture are more self-contained; they announce changes and trust that other parts of the system will listen and respond if they have a vested interest in the event.

While request-driven collaboration is characterized by active, direct communication to fulfill immediate needs, event-driven collaboration promotes a more indirect, reactive interaction based on state changes signaled by events. Each approach leads to different architectural decisions and ways of thinking about component interactions.

An event essentially is a testament that something of relevance has happened and are inherently immutable: Once an event occurs, it represents an irreversible fact