You are here: » Home » Blogs » Why are CQRS and Event Sourcing good options for instant payments?

Why are CQRS and Event Sourcing good options for instant payments?

17 December 2020

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 and Event Sourcing in a nutshell

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.

Key Features of Instant Payments

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.

Why are CQRS and Event Sourcing good for instant payments?

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: 

  • Efficient and non-blocking writes: Every business critical change is recorded as a domain event by the write side, with the benefit of not maintaining the separate current state and as a result eliminating the risk of contention by removing the need of update in-place.
  • Efficient read-side queries with complex view models, without impacting the command side: A variety of read models and complex projections are created by fetching the data from the write side as part of projection/synchronisation, without impacting the overall payment processing.
  • Independent scaling of teams and use of technology: The separation of the read and write side also brings wider decoupling of teams and technology. Teams can be scaled independently and benefit from using specific technology options and optimisations for different needs without impacting each other.
  • No need to maintain a separate execution history: Domain events are immutable facts representing business critical change in state. The current state is built based on the domain events, as well as the business critical execution history.
  • Consistent state management: Domain events become the single source of truth, eliminating the risk of publishing a domain event to the outside but failing to update the state consistently.
  • Improved self-healing and troubleshooting: In case of temporary failures, recorded domain events can be replayed again to recover the application state to allow self-healing, debugging or troubleshooting.
  • Easier archiving on immutable data: It is much safer to archive immutable domain events to a slower storage.
  • Object model doesn’t have to be same as the data model: More focused data modelling from the very beginning as commands are modelled to contain only the concise information needed to make a decision on how to handle.

Understanding the Business Case

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.

Utilising CQRS and Event Sourcing in IPF

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:

 

 

Categories: Banking Blog cloud Instant Payments open banking Payments Payments Transformation Payments Transformation Race Real Time Payments

Sirin Sevinc

BACK TO BLOGS