Event‐sourced, observable software architectures: An experience report

Abstract

The speeding growth of the IT market and the spreading of disruptive technologies are leading towards more and more risky operations in need of constant upkeep, monitoring as well as proactive orchestration. On the one hand, the property allowing a system to be catered by automated monitoring and healing technology is defined as observability . On the other hand, appropriate design principles to manifest observability were originally referred as event sourcing by its inventor Martin Fowler and warrant for the aforementioned sustainable software operations. Both event sourcing and observability are complex to leverage on and design for. In an effort to understand more on both concepts, we offer an experience report on their practical use, featuring: (1) a rigorous definition of software architecture observability and a set of principles to design for observability using augmented forms of well-known design patterns in line with event sourcing; and (2) an impact analysis in the context of a case study. Our study reveals several interesting notions around the concept of observability but our findings also make explicit new architecture trade-offs that software architects and stakeholders need to consider as first-class architecture-level concerns.

Diseño e implementación de una arquitectura de microservicios orientada a trabajar con transacciones distribuidas

“…Por este motivo, esta investigación se centra en la generación de una arquitectura que pueda superar este inconveniente, proponiendo diferentes patrones de implementación como lo es el patrón SAGA el cual es una secuencia de transacciones, donde si alguna transacción viola una regla de negocio, se ejecuta una compensación mediante la invocación de una operación que deshaga lo realizado anteriormente [2]. El patrón Event Sourcing que nos permite evitar una arquitectura de tipo "Solicitud y respuesta", añadiendo latencia a los microservicios, donde de forma asíncrona se notifique a al bus de servicios de la transacción y luego en él se pueda procesar la misma en caso tal sea necesario [3]. Estos dos patrones se verán a detalle en la investigación y como en conjunto estos patrones habilitan a la arquitectura para procesar transacciones en diferentes circunstancias tales como: transacciones asíncronas, transacciones síncronas, cancelación de una transacción en proceso, y relanzamiento de transacción.…”

Design and Implementation of a Model-Driven Software Production Method: from Strategy to Code

“…Several design patterns aim to organise the subdomains into one or more deployable and executable components (Richardson, 2018), such as the saga pattern (Štefanko et al, 2019) to implement distributed transactions as a series of local transactions, and the API composition pattern, to resolve queries by joining data from separated databases (Richardson, 2018). Approaches such as event-sourcing (Alongi et al, 2022) help to manage the complexity of large, distributed systems by providing observability, this is, a system's attribute regarding how much and well the internal state of a system can be inferred through a monitoring infrastructure (Muller, 2018). These practices and patterns address the requirements set by the SOs approach for software design.…”