Chris Tacey-Green, speaking at a recent industry event, delved into the intricacies of implementing event-driven architectures (EDAs) within highly regulated sectors such as banking and aviation. His presentation, "Event-Driven, Cloud Native, Banking," aimed to demystify EDAs for those new to the concept while offering valuable insights for experienced practitioners, particularly concerning their application in environments demanding stringent compliance and robust reliability.<\/p>\n
Tacey-Green began by dissecting the fundamental elements of an event-driven architecture. At its heart, an "event" is defined as a change in the state of a system. This change can be triggered by various sources, including user actions, asynchronous background processes, or external systems. Events can either carry data, referred to as "fat events," or serve as simple notifications, termed "thin events." Tacey-Green advocated for "lean" events, suggesting that events should carry all pertinent data without extraneous information, drawing a parallel to a well-known paper advocating for "putting your events on a diet."<\/p>\n
A crucial distinction was drawn between "events" and "commands." Tacey-Green emphasized that while commands represent a direct instruction to perform an action, often with an expectation of a result, events are declarations that something has already happened. "An event is me shouting into the world saying that something happened," he explained. "I’m not expecting anything to happen off the back of that. I’m not necessarily expecting anyone to be listening to me." This clear differentiation, he noted, is vital for avoiding common pitfalls that can undermine the benefits of an EDA.<\/p>\n
An event-driven architecture, therefore, is an ecosystem where multiple systems react to these emitted events. These systems typically comprise "producers," which publish events, and "consumers," which subscribe to and process them.<\/p>\n
Tacey-Green also clarified the relationship between EDAs and "event sourcing." While often discussed in the same context, they are not interchangeable. Event sourcing is a specific pattern for representing the state of an application as an immutable sequence of events. For instance, in a shopping cart scenario, instead of storing the state as "4 hats," event sourcing would record four individual events: "add hat," "add hat," "add hat," "add hat." While event sourcing can complement EDAs, it is not a prerequisite. He cautioned that event sourcing can be a complex pattern to implement, and teams should understand that an EDA can be achieved without adopting it.<\/p>\n
The "cloud-native" aspect of the title refers to the design, construction, and operation of workloads in the cloud using modern engineering practices, emphasizing scalability and DevOps principles like CI\/CD. Finally, "banking," as Tacey-Green described it, involves large, traditionally slow-moving, and highly regulated organizations. He contrasted the cautious nature of many traditional banks with the modern, agile approach adopted by his employer, Investec, which is actively embracing these advanced architectural patterns.<\/p>\n
The presentation then transitioned to the "why" behind adopting EDAs, especially in high-stakes environments like banking. Tacey-Green highlighted several key benefits derived from real-world use cases:<\/p>\n
A primary advantage is decoupling, which significantly enhances system independence and resilience. Tacey-Green illustrated this with the example of transaction monitoring at a bank. Traditionally, integrating a payment system with a transaction monitoring service could lead to tight coupling. This could involve payments directly calling a transaction monitoring API or vice-versa. Such coupling creates dependencies that can impact reliability and slow down development, especially when systems have different reliability expectations or operational requirements.<\/p>\n
By adopting an EDA, payments systems can publish events like "payment initiated" or "payment processed" without any knowledge of transaction monitoring. Transaction monitoring, as an independent consumer, can subscribe to these events, extract the necessary data, and perform its analysis. This decoupling means that if the transaction monitoring system experiences downtime, it does not affect the core payment processing flow. Conversely, the payment system can evolve without directly impacting the transaction monitoring service. This separation is critical in regulated industries where core functions like payments must remain highly available, while auxiliary services may have different uptime SLAs.<\/p>\n
EDAs naturally create an immutable log of all system activities, which is invaluable for auditability and traceability in regulated sectors. Before implementing an EDA for payments, Tacey-Green explained, understanding the precise journey of a payment through various checkpoints (fraud checks, sanctions screening, gateway selection) was challenging. With an EDA, each step generates a distinct event, forming a comprehensive and trusted record. This is not a separate audit log but the very record of how the system operated. Business-oriented event names, like "payment initiated" or "fraud check completed," provide clear visibility into the payment lifecycle, aiding in investigations and compliance reporting.<\/p>\n
The "fan-out" pattern, where a single event triggers multiple independent downstream actions, is another significant benefit. Consider a payment processing event. This single event can simultaneously trigger updates to customer payment limits and initiate customer communications (e.g., push notifications, SMS, email). In a traditional, tightly coupled system, coordinating these actions and handling failures in one could be complex. With an EDA, the "payment processed" event can be published once, and independent services for payment limit updates and customer communications can consume it. This allows each service to manage its own fault tolerance and retries without impacting the others, promoting greater system robustness.<\/p>\n
In regulated industries, fault tolerance is not a luxury but a necessity. EDAs offer multiple layers of fault tolerance. Tacey-Green outlined three tiers:<\/p>\n
As EDAs mature, they enable a "plug-and-play" approach for introducing new capabilities. If core systems like payments or accounts publish well-defined domain events, new services, such as a rewards program, can be built by simply subscribing to these existing events. This eliminates the need for direct integrations with the core systems, accelerating development and reducing dependencies. For example, a new rewards service could automatically know when a client is onboarded, an account is created, or a payment is processed, simply by consuming the relevant events.<\/p>\n
While the benefits are substantial, Tacey-Green candidly addressed the inherent challenges of implementing EDAs, particularly in a regulated context.<\/p>\n
The most significant challenge, he noted, is not technological but human. "Event-driven architectures are hard for people, mainly people who have not yet worked on those architectures before," he stated. This learning curve can impact the speed of delivery, with new team members potentially taking months to reach parity with experienced engineers. The shift in paradigm requires architects and developers to think differently, moving from imperative to declarative programming models and embracing concepts like eventual consistency.<\/p>\n
What helps:<\/strong><\/p>\n In regulated industries like banking and aviation, the loss or duplication of events can have severe financial and compliance consequences. For example, a lost payment event could mean a landlord never receives rent, while a duplicated payment could lead to customer disputes and financial penalties.<\/p>\n What helps:<\/strong><\/p>\n Events form a contract between producers and consumers. Once an event is published to an immutable event stream, it cannot be easily altered. Breaking these contracts by changing event structures or data can lead to cascading failures in consumer systems.<\/p>\n What helps:<\/strong><\/p>\n Cloud-native eventing technologies are often optimized for scale and may not guarantee event order. In scenarios where order is critical (e.g., processing a series of transactions for a single account), this can lead to issues like allowing duplicate high-value payments if the balance update event hasn’t been processed yet.<\/p>\n What helps:<\/strong><\/p>\n Tacey-Green concluded by illustrating these concepts with a detailed diagram depicting the flow of events between "payments" and "communications" domains within a banking context. The diagram showcased the journey of a payment from an API call, through the outbox pattern for event publishing, into the event stream, and then consumed by the communications domain via an inbox pattern. It highlighted the transformation of domain events into integration events, the role of publishers in filtering, aggregating, and transforming events, and the overall protection mechanisms implemented to ensure reliability and compliance. This visual representation underscored how these architectural patterns, when integrated into a developer platform, can empower teams to build robust and scalable EDAs in regulated environments.<\/p>\n The discussion also touched upon key questions from the audience, including defining event versions, proving completeness of event streams for auditors (SOX compliance), managing the cost of deduplication, handling a large number of integration events, and the trade-offs between lean and fat events. Tacey-Green’s responses emphasized practical solutions and the importance of careful design and trade-off analysis.<\/p>\n Ultimately, Tacey-Green’s presentation offered a comprehensive guide to navigating the complexities of event-driven architectures in highly regulated industries, underscoring that with careful planning, robust tooling, and a focus on human factors, these powerful architectural patterns can be successfully implemented to drive innovation and efficiency.<\/p>\n","protected":false},"excerpt":{"rendered":" Chris Tacey-Green, speaking at a recent industry event, delved into the intricacies of implementing event-driven architectures (EDAs) within highly regulated sectors such as banking and aviation. His presentation, "Event-Driven, Cloud Native, Banking," aimed to demystify EDAs for those new to the concept while offering valuable insights for experienced practitioners, particularly concerning their application in environments …<\/p>\n","protected":false},"author":9,"featured_media":5420,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[136],"tags":[905,909,910,138,258,904,908,907,139,906,137],"class_list":["post-5421","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-development","tag-architectures","tag-benefits","tag-challenges","tag-coding","tag-driven","tag-event","tag-foundations","tag-industries","tag-programming","tag-regulated","tag-software"],"_links":{"self":[{"href":"https:\/\/lockitsoft.com\/index.php?rest_route=\/wp\/v2\/posts\/5421","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lockitsoft.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lockitsoft.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lockitsoft.com\/index.php?rest_route=\/wp\/v2\/users\/9"}],"replies":[{"embeddable":true,"href":"https:\/\/lockitsoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5421"}],"version-history":[{"count":0,"href":"https:\/\/lockitsoft.com\/index.php?rest_route=\/wp\/v2\/posts\/5421\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/lockitsoft.com\/index.php?rest_route=\/wp\/v2\/media\/5420"}],"wp:attachment":[{"href":"https:\/\/lockitsoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lockitsoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lockitsoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
The Perils of Duplicated or Lost Events<\/h4>\n
\n
\n
The Challenge of Breaking Event Contracts<\/h4>\n
\n
v1<\/code>, v2<\/code>), is essential. A data_version<\/code> property within the event metadata allows consumers to handle different versions gracefully.<\/li>\nEvent Ordering and Its Implications<\/h4>\n
\n
A Holistic View: The Payments and Communications Example<\/h3>\n