by Federico Gonzalez

The ability to operate continously with no downtime is a key feature of payment systems.

That feature is commonly referred to as “high availability”, or simply HA, and involves both software and infrastructure elements like network components.

Not only is it desired for performance and business continuity reasons, but also for PCI compliance.

This piece focuses on a HA strategy implementation for jPOS-based applications that leverages production-grade real-world proven jPOS components with no additional infrastructure requirements.

Please, note that this covers HA inside the boundaries of the application. Additional infrastructure elements are needed to load-balance the entry points of the payment system, such as API Gateways, layer 4 load balancers, among others.

Design pattern

The following is a common pattern used in a variety of deployments of jPOS-based applications:


Set ups like these can be easily achieved by using pure jPOS components with zero additional infrastructure whatsoever.

No additional code required. Just pure configuration.

In particular, the jPOS feature supporting this is MUXPool (see “Implementation details” below).

Key benefits

  • Allows for application components updates with no downtime.

  • Allows for both active/active and active/passive strategies (i.e. backup data centers or availability zones).

  • System load is evenly distributed across all component instances when using strategy=round-robin (see next section).

  • Zero code required.

  • There’s virtually no limit to the number of nodes that can be added up to the mix.

  • No third-party software or hardware involved that needs to be monitored and patched.

Implementation details

The implementation of this HA strategy is achieved by refactoring all MUXes so as to put a MUXPool before them.

Provided you got a MUX set up like the following…

<?xml version="1.0" ?>
<mux class="org.jpos.q2.iso.QMUX" logger="Q2" name="core-mux">

…rename it as core-mux-primary and set up a new MUX pointing to the other node, named core-mux-secondary.

Then, add a QBean descriptor for the MUX pool that will load-balance the traffic between both MUXes.

<mux class="org.jpos.q2.iso.MUXPool" logger="Q2" name="core-mux">
    <muxes>core-mux-primary core-mux-secondary</muxes>

That’s it.

Repeat the process for all the MUXes in the system where adding a connection to other node is feasible.

Other posts