Our Blog

Multi-active payments authorisation in a stateful world

High availability is a prerequisite for payment switches. Our customers rely on our technology being available all the time, including during application upgrades or when hardware failures occur. Additionally, it gives our customers more options if we allow them to scale out as well as up: for example, if a bank is processing volumes of transactions that cannot be handled by a single server or database then it’s comforting for them to know that Novate has the answer.

Novate addresses this problem by working at a higher level of abstraction than a single switch. Within Novate, we have the concept of a switch topology, within which it is possible to define multiple switch instances. For example, a typical production installation of Novate will include at least two switch instances, in conjunction with at least two switch databases, handling the OLTP authorisation traffic. The beauty of this approach is that Novate administrators can control the operation of their topology via a single web console, and can see at a glance the volumes that each switch instance is handling at any one time, down to the individual acceptor or destination.

It is also possible to bring new nodes on stream without taking any downtime – simply spin up a new switch node instance, add it to the topology, and off you go.

Additionally, Novate has abstracted out the concept of a switch database itself – so (for example) a single Novate switch node can be configured to write transactions to a single database, to multiple databases, or to fallback to a second (or third) database if the preferred database is not available.

There is no silver bullet to attaining high-availability – it is a multifaceted and multidisciplinary process, and we at Aviso understand this well. With the Novate architecture, each part of the architecture has been carefully designed with high availability in mind. For example, we recommend that each switch database in our topology be configured as a ‘database block’ consisting of one active and two standby databases, using synchronous replication. This configuration on its own provides 99.9999% availability within a single database block. On top of this, Novate also layers on multi-active support, where multiple such database blocks (and multiple attendant switch instances) are supported. For example a second database block with a switch node can be housed in a second data centre, giving cross-data centre resiliency.

Payments experts among you will no doubt have a question: how do you handle stateful transactions? Some transaction types have state – for example some transaction types (including APACS 40) include Message Authentication Codes (MAC’s) that are generated using a Derived Unique Key Per Transaction (DUKPT) algorithm. Such MAC authentication mechanisms require access to the previous transaction in order to properly validate the MAC. This can cause problems in an multi-active, shared-nothing architecture.

Novate can handle this requirement in a couple of different ways. First of all, the Novate database has been designed so that stateful data is stored in a small number of discrete tables. This reduces the problem set down to a small, manageable data set size.

Secondly, a Novate topology that handles stateful transactions will typically employ asynchronous multi-master replication (using GoldenGate for Oracle, or Londiste or Postgres asynchronous replication for Postgres) across each database block. Asynchronous replication gives high performance, non-invasive replication across an active-active deployment, so that (for example) a credit card terminal can dial into any Novate switch instance in a topology and have the transaction MAC be properly validated.

A word of caution: multi-master replication sounds like a panacea for highly available systems, but it’s not – there are workloads to which it is not suited. Thankfully payment transaction processing load profiles work very well with multi-master replication, so it’s something that Novate can take advantage of. In combination with transaction sharding (which I will touch on in a future blog post) these building blocks give Novate a very firm basis to extend to the most demanding of transaction workloads and processing environments.