In the second part of our series exploring the motivations, architecture and principles driving the development of IPF, Sirin Sevinc, Senior Solution Architect, explains the roles CQRS and Event Sourcing play in supporting payments innovation.
CQRS (Command Query Responsibility Segregation) and Event Sourcing are not new patterns. They have been around for many years and their popularity has been increasing in synch with the demand for high-throughput low latency distributed systems.
But what exactly are CQRS and Event Sourcing and why are they a good option for instant payments?
CQRS is an architectural pattern that separates processing commands and answering queries.
The ‘write part’ processes commands and manages updates to the application state. It is modelled and built independently from the ‘read part’, which is responsible for responding to the queries. It is this separation that allows us to address distinct concerns for each part and apply specific optimisation strategies, without impacting the other.
It’s quite common to see CQRS implementations combined with Event Sourcing, which is a way of representing the application state by constructing it from the history of events. In event sourced applications, it is not just the current state that is important but also the steps of how it got there. It is this approach eliminates the risk of inconsistencies such as publishing an event while failing to update the current state. In addition, the audit trail comes for free as it becomes a critical part of the domain.
Event Sourcing is a natural fit for CQRS when modelling the command processing side. It is used to model the ‘write’ side of CQRS by recording every critical state change of a business entity as distinctive domain events. Those events can then be used to construct the current state when needed.
Another important term is the domain events which form the key part of the application and it is critical to model domain events to reflect business processes. An increasingly used event modelling technique is ‘Event Storming’, which facilitates higher collaboration between domain experts and technologists. This helps us better understand business processes and translate them into domain events that can be event sourced.
The query side on the other hand is built independently, based on various projection requirements and allows future extension and variety of view models without impacting the command model.
The payments domain is a very rich and complex business domain with many kinds of payment types based on geography, currency, different service level agreements (SLAs), regulatory checks, validations, execution steps, exception handling, and clearing and settlement mechanisms.
Instant payments is one of the sub-domains within the complex payments domain with distinctive requirements and imposes significant demands on payment applications. These include fast to real-time processing times, myriad checks and controls on payment data, instant decisioning and fund access along with real-time clearing and settlement mechanisms. 24/7 reliability and availability are also critical.
To meet these demands, instant payment solutions must support high-throughput and low-latency payments processing, handle failures gracefully and cope with load in a reactive and cost-effective manner with no bottlenecks. Solutions must also stay responsive under load to ensure consistent response times, as well as during failures to provide interactive feedback.
In short, solutions should be able to cope with distributed systems problems efficiently and naturally to support reactive systems characteristics.
A solution that combines CQRS with ES and applies it to an instant payments domain can answer to the high demands of instant payments processing with significant advantages:
Of course, it only makes sense to use a pattern or architecture style if it is going to solve your problems. We have seen that CQRS and Event Sourcing present advantages, but it is also imperative to understand the trade-offs and possible impact of introducing such solutions to an application.
For example, with CQRS there is a natural lag between the writes and reads and the data updates may not be immediately available on the read side. Also, a shift from traditional design-thinking comes with a learning curve.
While Event Sourcing is a natural fit for CQRS, potential reliance on a third-party framework, ensuring backward compatibility, increased data volume and challenges in duplicate checking are all factors that should be carefully considered.
Identifying a clear business case is a critical part of any technology initiative, and this is no different with CQRS and Event Sourcing where benefits should be assessed alongside the potential costs.
While CQRS and Event Sourcing are not ‘silver bullets’, they are certainly good patterns for instant payments solutions, enabling high-throughput and low latency-payments processing while enhancing abilities such as self-healing, troubleshooting and extensive audit logging.
For this reason, our collaborative payments platform, IPF, combines CQRS and Event Sourcing along with domain driven design and hexagonal architecture principles.
Together, this provides a decoupled, scalable, low-cost, high-performance application. The flexible and modular framework allows us to embrace unique bank requirements and promote payments innovation, without disrupting the core product components and principles. Through IPF, Icon has the ability to build client-specific payment applications which integrate to proprietary systems while benefiting from a consistent core domain. This is the result of deep payments expertise and the implementation of highly efficient design patterns like CQRS and Event Sourcing.
To find out more about CQRS and Event Sourcing, download the full overview.
This article was inspired by: