Back to all use cases

ConsultingCross-Industry

A second site is a plan only after someone has switched over to it

Data Platform Team

What a disaster recovery engagement covers when a second site exists on paper for three platforms and nobody has switched over to it.

Overview

A typical engagement starts when a risk questionnaire or an auditor asks for recovery time and recovery point evidence for the messaging and database platforms, and the answer is a wiki page. AceMQ sets the targets with the business, maps them to what each platform can do, tests the switch-over and writes the runbooks.

Challenge

Each platform recovers in a different way and has a different limit. Kafka needs a cluster in each site and mirroring between them, RabbitMQ federation or shovel does not replicate acknowledgements so consumers see duplicates after a failover, and PostgreSQL replication is asynchronous unless it is made synchronous at a cost in commit latency. No one has agreed what data loss each workload can tolerate, and the failover steps have never been run together.

Environment

A primary and a secondary data centre or region, Kafka and RabbitMQ on virtual machines and Kubernetes, PostgreSQL behind an automated failover tool, and applications that connect across all three.

Approach

AceMQ starts from recovery point and recovery time targets per workload that the customer sets, not from a uniform posture. It maps each target to the mechanism that can meet it, fixes the gaps found, and proves the design with deliberate failure tests in an agreed window before handover.

Solution

  1. Recovery point and recovery time targets recorded per workload, with the data-loss tolerance written in plain terms
  2. A mapping from each target to Kafka mirroring, RabbitMQ federation or shovel, and PostgreSQL archiving and replication settings
  3. Consumer changes specified where duplicates are possible after a failover, so redelivery is handled by design
  4. A test plan covering broker loss, site loss, network partition and a PostgreSQL primary loss, with the results recorded
  5. Runbooks for the automated path and the manual path, for failover and for failing back
  6. A test schedule tied to the recovery targets, and the support tier the customer chooses for the platforms afterwards

Outcome

The customer ends up with recovery targets agreed per workload, measured results from a failover test instead of an assumption, runbooks its own engineers can follow and a test schedule that fits its targets.

Technologies

KafkaRabbitMQPostgreSQLKubernetes
  • Consulting

    PostgreSQL High Availability and Failover Design

    Telecommunications OperatorTelecommunications

    Designing an automated failover architecture with quorum-based leader election, synchronous replication policy, and tested recovery procedures.

    PostgreSQLPatroniKubernetesetcdHAProxy
    Read case study: PostgreSQL High Availability and Failover Design
  • Assessment

    Airbyte Pipeline and Connector Estate Assessment

    Insurance Services GroupCross-Industry

    A structured review of an Airbyte estate that had grown organically — auditing connector versions, sync modes, state handling, and failure visibility.

    AirbyteKubernetesPostgreSQLdbtKafka
    Read case study: Airbyte Pipeline and Connector Estate Assessment
  • Assessment

    WSO2 Platform Architecture Assessment

    National Postal and Logistics OperatorCross-Industry

    Reviewing a WSO2 deployment's topology, database layout, high availability posture, and gateway sizing against its actual traffic profile.

    WSO2KubernetesPostgreSQLKafkaDocker
    Read case study: WSO2 Platform Architecture Assessment
  • Consulting

    Choosing Debezium + RabbitMQ over Kafka for Change Data Capture

    American National InsuranceHealthcare

    American National Insurance chose a standalone Debezium + RabbitMQ architecture for SQL Server change data capture after judging Kafka too complex to run for the job, keeping operations lean and routing flexible.

    KafkaRabbitMQDebeziumKubernetes
    Read case study: Choosing Debezium + RabbitMQ over Kafka for Change Data Capture

Related Reading

Need Kafka Architecture Guidance?

AceMQ's senior Kafka engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.