App Connect Enterprise (ACE) achieves high availability (HA) for its stateless integration servers by running multiple, independent replicas. A load balancer distributes traffic among these active instances, and if one fails, traffic is simply redirected to the others. This architecture does not require a quorum-based consensus among the ACE nodes.

Similarly, Aspera High-Speed Transfer Server provides HA through an active-passive configuration. In this model, a primary server handles all operations while a standby server monitors it. If the primary fails, the standby takes over its identity and functions. This failover mechanism does not depend on a quorum.

A. MQ: Native HA for MQ explicitly requires a three-node quorum to replicate data and elect a leader, preventing split-brain scenarios.

D. Event Streams: Built on Apache Kafka, which uses a ZooKeeper ensemble for cluster coordination. ZooKeeper requires a quorum (a majority of nodes) to be operational.

E. API Connect: The management subsystem's database cluster requires a quorum (a majority of pods) to remain functional and ensure data consistency.

1. App Connect Enterprise: IBM Documentation

"High availability for integration servers". It states

"Because integration servers are stateless

you can achieve high availability by running multiple replicas of an integration server." This model of independent

load-balanced replicas does not use a quorum. (IBM Cloud Pak for Integration documentation

App Connect

High availability).

2. Aspera: IBM Documentation

"Aspera High-Speed Transfer Server Admin Guide"

Section: "High Availability Active/Passive". This section details the two-node active-passive setup with a floating IP address

a classic non-quorum HA architecture.

3. MQ: IBM Documentation

"Native HA". It specifies

"A native HA group consists of three queue managers... The three nodes communicate with each other... determining which is the active queue manager. This is known as the quorum." (IBM MQ 9.3.x documentation

High availability

Native HA).

4. Event Streams: IBM Documentation

"Planning for an enterprise deployment of Event Streams". It explains that the ZooKeeper nodes

which manage the Kafka cluster

"form a quorum" and that "an odd number of servers is required". (IBM Cloud Pak for Integration documentation

Event Streams

Planning for high availability).

5. API Connect: IBM Documentation

"High availability and disaster recovery for the management subsystem". It states

"For a management subsystem to remain fully functional

a majority of the database pods in the cluster must be available (a quorum)." (IBM API Connect 10.x documentation

Deploying

High availability and disaster recovery).