RabbitMQ 4.3 and Khepri: What Changed for Laravel Microservices

RabbitMQ’s release history is usually a quiet list of incremental improvements. The 4.3 release in April 2026 crossed a threshold that had been building for two years: Khepri is now the sole metadata store, Mnesia is gone, and the minimum Erlang requirement moved to 27.0.

For most teams, a RabbitMQ upgrade is a matter of following the version compatibility matrix, running the upgrade, and moving on. This one warrants more attention, because the metadata store change is architectural, and the failure modes it eliminates are the ones most likely to appear during the events you most want your message broker to survive.

What Mnesia was and why it was replaced

RabbitMQ has used Erlang’s Mnesia database for cluster metadata since its earliest versions. Mnesia stores the broker’s core state: exchanges, queues, bindings, vhosts, and user permissions. It is distributed, in-memory, and tightly coupled to the Erlang node that hosts it.

The fundamental problem with Mnesia in a distributed RabbitMQ cluster is its handling of network partitions. When two nodes in a cluster lose connectivity temporarily — a brief network interruption, a rolling upgrade, or a VM migration — Mnesia can enter a split-brain state. Both sides of the partition believe they are the authoritative copy of the metadata. When the network reconnects, reconciliation requires manual intervention: decide which partition to keep, discard the other, and restart affected nodes.

Khepri is a Raft-based metadata store built specifically to replace Mnesia. Raft is a consensus algorithm that requires a quorum of nodes to agree before committing a change. Split-brain is structurally prevented rather than detected and recovered from. A minority partition becomes unavailable rather than diverging.

What changes in practice for a Laravel application

For the application code, nothing changes. Laravel’s rabbitmq driver (via the vladimir-yuldashev/laravel-queue-rabbitmq package) connects to RabbitMQ over AMQP. The AMQP protocol surface is identical. Queue declarations, message publishing, consuming, and acknowledgement all work the same way.

The changes are operational:

Cluster recovery is faster and requires less intervention. After a network partition or a rolling restart, a Khepri-backed cluster recovers automatically once a quorum of nodes is reachable. With Mnesia, the common recovery path involved consulting the partition handling documentation, choosing a recovery mode, and often restarting nodes manually.

The minimum Erlang version is now 27.0. Check your current Erlang version before upgrading:

erl -eval 'erlang:display(erlang:system_info(otp_release)), halt().' -noshell

If the output is below 27, the Erlang runtime must be upgraded before RabbitMQ 4.3 will start. In containerised deployments, this is a base image change; the official RabbitMQ Docker image already ships with the correct Erlang version for each tagged release.

Global QoS is denied by default. In 4.3, a basic.qos with global=true is silently converted to per-consumer prefetch (global=false). If your Laravel queue workers set a global prefetch somewhere in a custom consumer setup, verify the effective behaviour after upgrading. The standard laravel-queue-rabbitmq driver uses per-channel prefetch by default, so most teams will not be affected.

Topic exchange binding keys have stricter validation. The # wildcard in a topic binding key is now limited to two occurrences, and the recommendation is to use # as the final segment only. Binding patterns like #.errors.# will be rejected. This is relevant if your microservice topology routes events through topic exchanges with multi-segment wildcard patterns.

Quorum queues: the operational recommendation

RabbitMQ 4.3’s enhancements to quorum queues — 32 strict priority levels and native support for delayed retries and consumer timeouts — reinforce the long-standing recommendation to migrate away from classic queues. Classic queues lack the durability and partition tolerance guarantees that quorum queues provide.

For Laravel applications, declaring a quorum queue requires setting the x-queue-type argument:

// In a RabbitMQ-aware service provider or queue bootstrap
use PhpAmqpLib\Wire\AMQPTable;

$channel->queue_declare(
    queue: 'laravel_jobs',
    passive: false,
    durable: true,
    exclusive: false,
    auto_delete: false,
    nowait: false,
    arguments: new AMQPTable([
        'x-queue-type' => 'quorum',
    ]),
);

Quorum queues require at least three nodes for effective replication (the quorum is a majority of replicas). A single-node RabbitMQ setup should use classic durable queues or acknowledge that quorum guarantees are not available in a single-node configuration.

Upgrade checklist for teams running Laravel on RabbitMQ 4.2 or earlier

RabbitMQ 4.2 reached end-of-life on July 31, 2026 and no longer receives security patches. The upgrade path from 4.2 to 4.3 is:

[ ] Confirm Erlang 27.0+ on all cluster nodes
[ ] Review topic exchange binding keys for multi-segment # wildcards
[ ] Audit any custom consumer code that sets global=true on basic.qos
[ ] Test the upgrade on a staging cluster before production
[ ] Verify the official Docker image tag if containerised (rabbitmq:4.3-management-alpine)
[ ] Check the 4.3 release notes for the full deprecation list
[ ] After upgrade: verify queue type declarations match the new cluster state
[ ] Update monitoring alerts: the management API response shape for some cluster stats has changed

The transition from Mnesia to Khepri is a substantial underlying change. The upgrade itself, for teams with modern Erlang and clean binding patterns, is straightforward. The operational benefit — cluster partitions that recover automatically instead of requiring a maintenance window — is real and worth the upgrade cycle.