Bloomberg publishes BlazingMQ, a modern high-performance open source message queuing system

Some notable attributes of BlazingMQ:

• A rich set of features that enable enterprise applications to implement complex workflows.
• Battle-tested in production at Bloomberg; survives node crashes, restarts, network disturbances, hardware failures, etc.
• Consistently provides low latency under heavy traffic. Users can expect low end-to-end median (p50) latency of less than five milliseconds for queues configured with persistence, multi-node replication, and strong consistency.
• Excels in environments with high fan-out (large number of consumers for a queue), which leads to significant network bandwidth and storage savings in such scenarios.

How did you come to work on this project? Who else has contributed?

Vincent Yan: When I first joined Bloomberg around six years ago, I started out on an application development team. The work was important and impactful, and I genuinely enjoyed the team atmosphere. However, I preferred low-level back-end work, ideally focused on distributed systems and networking, both of which I researched during college.

During training, I had the opportunity to learn about different teams within our Engineering department, and was immediately drawn to the BMS – Queuing team. They work on BlazingMQ, a crucial piece of distributed messaging middleware, specifically putting a lot of focus on low-latency, high throughput, and high reliability.

At the time, the software was still relatively new, so there were lots of cool features to work on, while the code quality and CI/CD pipeline were also superb. Julien, the team lead then, had an illuminating discussion with me, where he described all the interesting challenges in BlazingMQ. Moreover, we planned to publish it as open source from the outset, which was very exciting to me. The team definitely did not disappoint after I joined, and I hope BlazingMQ will continue to grow as a more attractive and mature solution as a result of this open source effort.

Lise Ho: Since college, I was always interested in distributed systems, and after using such systems in my prior roles, I decided that I wanted to go even deeper. When a friend mentioned they were working on building a super stable and resilient message queue solution from scratch, I was highly intrigued. Upon exploring some more, I learned of an opportunity to work on a high impact project related to BlazingMQ. There’s no better way to learn and understand a complex system than to actively work on it.

Ever since jumping at this opportunity, I’ve been challenged countless times while building more powerful features and system integrations for BlazingMQ. I’ve learned first hand how we invested in BlazingMQ’s stability and features. BlazingMQ is truly the product of a team effort across many years – and it’s one I’m excited to continue working on as we start this new open source chapter of BlazingMQ’s development!

Ankur: For me, it’s basically a story of being in the right place at the right time. Several years ago, when the BlazingMQ project had just been greenlit, I was looking to switch teams within Bloomberg’s Engineering department to find a better match for my skills and interests. I knew one of the engineers in the newly formed BMS – Queuing team from my new hire training, and after a quick chat with him and the management chain, I landed in this team.

As an aside, I want to give a quick shout out to the awesome internal mobility team members at Bloomberg who have helped several engineers like myself find their right team. In fact, all but one current team member moved into BMS – Queuing from another engineering team within Bloomberg!

As for who contributed to BlazingMQ’s development, that’s a long list! Over the years, several people have contributed to the project, and as much as I want to, it isn’t possible to list them all here. In addition to the current team members (and several other current and former Bloomberg employees), I would like to specifically mention a few names of people who have played a crucial role in bringing BlazingMQ to its current state: Julien Bibollet, Philippe Grenet, Ilougino Rocha, Sergei Galichkin, and Dan Katz.

What did you individually contribute to the project? How did your experience/background prepare you to make this contribution?

Taylor Foxhall: At the time we were really starting the push to publish BlazingMQ as open source, I had just joined the BMS – Queuing team from its sibling BMS – Streaming & Coordination team, so I had a lot to learn quickly! Fortunately, I already had more than two years of experience working with Apache Kafka, another open source distributed messaging project that my prior team offered as a managed service. Plus, I was particularly familiar with librdkafka, the de facto native C API for Kafka clients. So, I came in with some knowledge of the expectations an enterprise user might already have for a project like BlazingMQ. I think that perspective helped define how the team decided what our end goal should be.

I also had quite a bit of background with build systems, in particular CMake. I basically rewrote most of the build rules so we weren’t dependent on internal tooling and could better utilize open source solutions. I specifically wanted to make sure it would be easy for users to get started using our C++ APIs. I’m pretty happy with what we have, and I’m excited for a few ongoing efforts that will soon make it even easier.

Ankur: I joined the BMS – Queuing team as a senior engineer and transitioned into leading and managing the team a few years ago. Consequently, my role has changed from hands-on software development to managing the project, people, and our internal stakeholders. As a developer, I contributed towards some of the solution’s core subsystems and, to my mild surprise, most of my code has survived all these years!

If I look back at my career, I have always been generally interested in messaging systems, networks, and distributed systems, so I was able to hit the ground running in this team from the get go. BlazingMQ has always kept me on my toes and it has been a challenging, but very rewarding, experience for me.

Why did Bloomberg initially build this tool and how long has it been used internally?

Ankur: Back when Bloomberg’s software infrastructure engineers were looking to offer a generic message queuing solution across the firm, none of the solutions we surveyed at the time fit the bill. Some were in their infancy, some were proprietary and expensive, some lacked features, while others had question marks about their reliability or performance. After a careful review, coming up with a home-grown message queuing solution was determined to be the best course of action, especially since Bloomberg is a large enterprise with several non-trivial use cases. While it’s not always a clear cut decision to invest in a custom infrastructure solution, in my opinion, our effort to build BlazingMQ has been more than vindicated with its success at Bloomberg. And now we’re hoping that other organizations can benefit from its use as well.

What are some of the characteristics of BlazingMQ that make it different from other message queuing solutions?

Vitaly Dzhitenov: The functionality of a message queue may seem simple, but the landscape of architectural and design decisions is complex, requiring significant flexibility. For example, the combination of storage and data routing can completely change the shape of the solution. If you store data first, and then route it (BlazingMQ), you incur constant costs with fixed distribution. If you do the reverse (RabbitMQ), your distribution is flexible but your costs are proportional to the number of destinations. If you decide to decouple storage from routing, you will get a third, completely different product (Apache Kafka). The choice of message queue depends on many application-specific factors.

BlazingMQ provides a unique combination of simplicity, performance, fault tolerance, and features. It is an actively growing project with a high feature velocity. Not only do we have competitive latency numbers, but also we have identified paths to improve them further. This gives BlazingMQ the potential to succeed in the messaging systems space.

How will this solution benefit the broader open source and distributed computing communities?

Taylor: I’m happy enough just to see this nearly decade-old battle-tested C++ project be available in the open, where many different kinds of engineers, at all levels of experience, will be able to sink their teeth into the different systems that make up BlazingMQ. Large software projects written in C++ are quite difficult to understand, but I think BlazingMQ’s code is some of the more diligently maintained and cleanly put together C++ I’ve seen in the wild. Given its track record within a demanding enterprise environment like Bloomberg’s, I’m hoping it’s viewed as a serious and trusted solution for modern applications that need a message broker.

Ankur: Despite there being several open source solutions in the distributed messaging domain, I believe there is still demand for a modern message queuing solution which provides a set of core features and puts a premium on low latency. And, in my (admittedly biased!) opinion, BlazingMQ can fill this void quite well.

While we don’t claim BlazingMQ is the best messaging solution out there (because it isn’t, at least not yet!), it provides a very compelling option to developers thanks to its features, efficiency, and reliability. As we continue to improve BlazingMQ’s deployment ergonomics and developer experience in the coming months, I am cautiously optimistic that the community will give BlazingMQ a shot and that they will see its benefits for themselves.

What do you hope the community contributes to the project?

Jean-Louis Leroy: Throughout my career, I have developed several open source projects of my own, including Tangram, an object-relational mapper for Perl, and YOMM2, a library that implements open multi-methods in C++17, among others. My past experience interacting with open source user communities tells me we should expect to get pull requests with contributions to the source code itself and bug reports for BlazingMQ. More importantly, the community’s major contribution will be feature requests and interesting development ideas we have not imagined on our own. These will help us broaden our roadmap and avoid tunnel vision.

Taylor: As an in-house software solution, BlazingMQ adapted quite well to the needs of its users: Bloomberg engineers. However, the needs of the open source community goes far beyond that, so I see a lot of room for BlazingMQ to grow. My hope is that we’ve demonstrated that BlazingMQ is a promising technology solution that will continue to be supported by Bloomberg’s engineers, and, therefore, the open source community will have the good faith to give us the feedback we need to be able to thrive within their various deployment environments.

Ankur: I’d like to get feedback about the product from the community. As we open the product to a wider audience, my hope is that they will provide a unique and fresh perspective which not only keeps us honest, but also helps us improve BlazingMQ. Of course, I am also hoping the community highlights the good parts of the product, which will motivate the team.

I am also hoping that the community actively participates in building a richer ecosystem around BlazingMQ, whether it’s by helping us add more features or integrating it with other open source systems, implementing new plugins, developing client libraries in new languages, and so on! Lastly, I am also looking forward to hearing ideas which we had not thought of before that might take the product in directions we had not previously anticipated.

What are some upcoming things in BlazingMQ that you are excited about?

Ankur: Plenty of things! In a way, publishing BlazingMQ as open source is a first step for us, and we are excited to continue investing in BlazingMQ and working with the community to advance the product. Specifically, we will be publishing as open source a BlazingMQ Python SDK in the coming months, as well as BlazingMQ’s various testing suites (chaos, stress, fuzz, etc.). We will also be working to make BlazingMQ more secure and more resilient under heavy loads. Our detailed product roadmap can be found on the BlazingMQ website. Please check it out!