# BlazingMQ: Bloomberg's C++ Message Queue, and What Building It Actually Costs

> BlazingMQ is an Apache-2.0 distributed message queueing framework from Bloomberg, with brokers in C++ and client libraries in C++, Java and Python. The interesting question is not what it does but whether your team can carry a C++ broker build and a Docker-based cluster.

**bloomberg/blazingmq** — A modern high-performance open source message queuing system

- Repository: https://github.com/bloomberg/blazingmq
- Website: https://bloomberg.github.io/blazingmq/
- Stars: 3,215 · Forks: 198
- Language: C++
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/bloomberg-blazingmq

## The problem BlazingMQ solves, and for whom

BlazingMQ is a distributed message queueing framework. The README frames the general case plainly: a queue is a loosely coupled, asynchronous channel between producers and consumers, a mailbox where a producer drops a message and a consumer picks it up at its own leisure. Producers and consumers can isolate themselves temporally and spatially from each other. That is the same sentence you will find in any queue's introduction, so the differentiator is further down.

The broker is written in C++, and client libraries exist in C++, Java and Python. The README states the project has been battle-tested in production at Bloomberg for 8+ years. That history is the strongest signal in the repository, and it also tells you who the project was built for: teams with services written in C++ or on the JVM, running their own infrastructure, who care about queue semantics rather than about a hosted control plane. If your stack is Node, Go or Ruby, note that the README lists no client library for those languages. The C++, Java and Python libraries are the supported surface.

The feature list is where the project earns attention. The README names durable, fault-tolerant, highly available queues, plus routing strategies including work queues, priority, fan-out and broadcast, along with compression, strong consistency and poison pill detection. Those are not decorations. Priority and fan-out change how you model a topic; poison pill detection changes what happens when one consumer keeps failing on the same message. Teams that have hand-rolled those behaviours on top of a simpler broker will recognise the list immediately.

## How the broker, clients and CLI fit together

The repository contains three things: the BlazingMQ message broker, the BlazingMQ C++ client library, and a BlazingMQ command line tool. The Java and Python client libraries are maintained in separate repositories, blazingmq-sdk-java and blazingmq-sdk-python. That split matters operationally. Your broker version and your client version are versioned in different places, and the README does not describe a compatibility matrix between them.

The broker is the component you deploy as a cluster. The README points to a deployment article that describes installing a BlazingMQ cluster in a set of Docker containers along with a recommended set of configurations. So the intended topology is a multi-container broker cluster, not a single process you run next to your application. The docker/ directory in the repository is consistent with that.

Clients connect to the cluster and open queues. Routing strategy is a property of the queue, which is why the README describes work queues, priority, fan-out and broadcast as queue features rather than client features. A producer does not decide at publish time whether a message fans out; the queue was configured that way. This is a meaningful design choice. It keeps client code simple and puts the routing decision in cluster configuration, which is easier to audit but harder to change per message.

The command line tool is the third piece. The README names it but does not document its subcommands, so treat it as something to discover from the CLI's own help output rather than from the README. The repository also ships a Doxyfile, which indicates API documentation is generated from the C++ sources.

## Building BlazingMQ on Ubuntu 22.04 or Darwin

The README does not give a package install. It gives build scripts. bin/build-ubuntu.sh and bin/build-darwin.sh build BlazingMQ and its dependencies on Ubuntu 22.04.2 LTS and Darwin 22.6.0 respectively, and the README says they can serve as a basis to build on other systems. If your platform is neither of those, you are porting, not installing.

Plugins are selected at build time. The README gives this example, where you pass a comma-separated list of plugin names to the build script:

```bash
bin/build-ubuntu.sh --plugins plugin-1-name,plugin-2-name
```

The plugin names in that example are placeholders from the README, not real plugin names. Substitute the plugins you actually need; the README does not enumerate them.

There is a second path through vcpkg. The README states that you must acquire flex, bison and bde-tools yourself, because vcpkg cannot fetch them. flex and bison are usually available from your system package manager. bde-tools is cloned from Bloomberg's bde-tools repository; the README's guide assumes it lives at blazingmq/thirdparty/bde-tools. Once those are in place:

```bash
export VCPKG_ROOT=/path/to/vcpkg
cmake --preset [preset-name] -DCMAKE_PREFIX_PATH=/path/to/thirdparty/bde-tools
cmake --build cmake.bld
```

The preset names come from the *-vcpkg configurations in CMakePresets.json. The README does not list them inline, so open that file before running the configure step. Read the three lines literally: the build directory is cmake.bld, and the prefix path points at your bde-tools clone, not at a system install.

## First run: the Docker container path

For a first real use, the README does not ask you to build anything. It points to a getting started article that guides readers to build, install and experiment with BlazingMQ locally in a Docker container, and to a companion article covering intermediate and advanced features. A separate installation article describes installing a cluster across Docker containers with a recommended set of configurations.

That ordering is deliberate and worth following. The local single-container experiment lets you open a queue and move a message before you think about cluster topology. The cluster article is the one you want when you move past the experiment, because the recommended configurations are part of the deployment, not an afterthought.

The repository also carries a docker/ directory, which is where the container assets live. The README does not reproduce the docker run invocation or the environment variables in the top-level file, so the article is the source for the exact commands. What the README does make clear is the shape of the exercise: you end up with a broker inside a container, and you interact with it through the client library or the command line tool.

One practical consequence: your first client code will be C++, Java or Python. If you want to evaluate BlazingMQ from a language outside those three, the container will still run, but you will be driving it through the CLI rather than through a supported client library.

## The build is the adoption cost

The honest limitation is not a missing feature. It is the build. BlazingMQ is a C++ project built with CMake, and the README's own instructions require flex, bison and a clone of bde-tools before the vcpkg path will configure. That is a real prerequisite chain, and it is the kind of thing that goes stale quietly: a dependency bump upstream can break your build before it breaks anything in production.

There is also a platform boundary. The two build scripts target Ubuntu 22.04.2 LTS and Darwin 22.6.0. The README presents them as a basis for other systems, which is an accurate description of a starting point rather than a supported matrix. If your fleet is on a different distribution or a newer LTS, plan for porting work and budget it before you commit.

The client library split is a second cost. Because blazingmq-sdk-java and blazingmq-sdk-python live in separate repositories, an upgrade is not one operation. The README does not document a version compatibility statement between broker and clients, so you will be establishing that yourself.

Finally, consider the case where BlazingMQ is simply the wrong tool. If you want a managed queue with a control plane, per-message billing and no brokers to run, this is not that. If your organisation has no C++ build capacity and no appetite to acquire it, the Docker path gets you an evaluation but not a comfortable production story. And if your workload is a simple job queue inside one application, the cluster deployment described in the installation article is more machinery than the problem needs.

## How it differs from Kafka and RabbitMQ

The comparison people reach for is BlazingMQ versus RabbitMQ and Kafka, so it is worth being precise about the difference in approach rather than ranking them.

Kafka's model is an append-only partitioned log. Consumers track offsets, retention is time or size based, and replay is a first-class operation because the log persists independently of consumption. BlazingMQ's README describes queues with routing strategies and message delivery to consumers, with strong consistency and poison pill detection named among the features. Poison pill detection in particular implies the broker is tracking consumer failures on specific messages, which is a delivery-oriented concern rather than a log-offset concern. If your design depends on replaying a week of history to rebuild a downstream view, that is a log-shaped requirement, and the README does not describe BlazingMQ as a log.

RabbitMQ is the closer comparison in shape: queues, routing, acknowledgements. The practical difference visible in this repository is the implementation and the client surface. BlazingMQ's broker is C++ with C++, Java and Python clients, and the deployment guidance is Docker containers with a recommended configuration set. RabbitMQ's ecosystem is broader in language coverage and managed offerings. What BlazingMQ offers instead is the routing feature set in one broker (work queues, priority, fan-out, broadcast, compression) plus Bloomberg's stated 8+ years in production. If you are already a C++ or JVM shop, that trade can be worth making. If you are not, the client libraries decide it for you.

The README does not benchmark BlazingMQ against either system. Any performance comparison you see elsewhere is not coming from this repository.

## Maintenance, licence and upgrade exposure

The repository is not archived, and the last push was on 2026-09-23. That is the only maintenance signal available here, and it is a current one.

The README states the project is actively developed and has been battle-tested in production at Bloomberg for 8+ years. That is the project's own claim, and it is consistent with a repository that received a push yesterday.

Licensing is straightforward on its face. BlazingMQ is Apache 2.0 licensed, as found in the LICENSE file. The repository also carries licenses/ and licenses-binary/ directories plus NOTICES.txt and a NOTICE/ directory, which is the shape you expect from a project that vendors third-party code. Apache 2.0 includes a patent grant and requires attribution notices to be preserved. Whether those notices impose obligations on your particular distribution is a question for your legal team; the relevant files are in the repository for them to read.

Upgrade cost is the part the README does not cover. There are no release notes in the repository and no documented rollback procedure for a broker cluster. The deployment article describes installing a cluster with a recommended configuration set, but the README does not describe how to move an existing cluster to a new broker build or how to revert one. Before you run this in production, that gap is worth closing with the project's own documentation site, which the README links as the comprehensive documentation source.

## Conclusion

BlazingMQ fits teams already running C++ or JVM services that need a queue with routing strategies, compression and poison pill detection, and that can absorb a CMake, vcpkg and bde-tools build plus a Docker-based cluster deployment. It is the wrong first queue for a small team without C++ build capacity, and the wrong pick if you need a managed service or a wide connector ecosystem. Before committing, verify three things: that the queue properties you need (priority, fan-out, broadcast, compression, strong consistency) match your workload, that your platform is one bin/build-ubuntu.sh or bin/build-darwin.sh covers or that you can port them, and that the separate blazingmq-sdk-java and blazingmq-sdk-python repositories are acceptable dependencies for your client code.

## FAQ

### What is BlazingMQ?

BlazingMQ is an open source distributed message queueing framework from Bloomberg, licensed under Apache 2.0. The broker is written in C++, and client libraries are available in C++, Java and Python.

### How do I install BlazingMQ?

The README does not give a package install. It provides bin/build-ubuntu.sh and bin/build-darwin.sh, which build BlazingMQ and its dependencies on Ubuntu 22.04.2 LTS and Darwin 22.6.0, plus a vcpkg-based CMake path. For a first run, the README points to a getting started article that uses a Docker container.

### Which client libraries does BlazingMQ provide?

The C++ client library is in this repository. The Java and Python client libraries are maintained separately, in blazingmq-sdk-java and blazingmq-sdk-python.

### What is a message broker versus a message queue?

The README describes a message queue as a loosely coupled, asynchronous channel between producers and consumers, like a mailbox where a producer drops a message and a consumer picks it up later. BlazingMQ's broker is the back-end component that implements those queues and delivers messages between the two sides.

### Does BlazingMQ support priority queues and fan-out?

Yes. The README lists routing strategies including work queues, priority, fan-out and broadcast, alongside compression, strong consistency and poison pill detection. These are queue-level behaviours configured on the broker side.

## Sources

- [bloomberg/blazingmq on GitHub](https://github.com/bloomberg/blazingmq)
- [Issues](https://github.com/bloomberg/blazingmq/issues)
- [License: Apache-2.0](https://github.com/bloomberg/blazingmq/blob/main/LICENSE)
- [Project website](https://bloomberg.github.io/blazingmq/)
- [README](https://github.com/bloomberg/blazingmq/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bloomberg-blazingmq