This article is part of a series interviewing developers (not founders, not executives) working on software infrastructure to understand their work, how they got here, the projects they’re proud of, the incidents they’ve learned from, and what they’re curious about.

Branimir (LinkedIn; GitHub) is a Cassandra committer, and member of the Project Management Committee (PMC), currently working at IBM (via its acquisition of DataStax). With a PhD (University of Aarhus, 2005) on exact computation of real numbers, and years spent working on digital signals processing, natural language processing, and the last 11 years as a Cassandra committer at IBM, Branimir has an interesting background. One big recent project of his, released in Cassandra 5 (2024), allows users to swap out the Skiplist in the Log-Structured Merge Tree (LSM Tree) for a Trie, improving memory usage and storage efficiency for anyone who opts in.

Starting from the basics... how did you end up working on Cassandra? Were you into databases before DataStax?#

Not at all. In fact, I remember considering them boring in university... Then a recruiter contacted me at the right time and I spoke to people who made me think of concrete problems; this got me interested, landed me in good company and a good company to work for, and I've kept doing it for over a decade now.

Supporting the Trie in the LSM Tree was a big recent project. Can you tell us about some other big projects you've worked on in Cassandra?#

There have been a few. The first one was the deterministic token allocation, where we wanted to find a way to reduce the number of virtual nodes by selecting them algorithmically rather than randomly. I spent a rather long period of time crafting a solution and had it committed. It took a couple of years until it was used in earnest, and turned out to not be that suitable for the way people actually used Cassandra. But it did include a smaller piece, written for tables that don't use replication, that worked great once it was applied for each individual rack, which ended up being both a simpler and better solution.

More recently, I worked with a team of people on modernizing Cassandra's compaction strategies, which resulted in Cassandra 5's Unified Compaction Strategy. We started by looking at the results from academia and compared them to our legacy compaction strategies to figure out how to build a more flexible solution that can cover them. After implementing this, we used it in DataStax's private branch to successfully handle densities an order of magnitude higher than what was typical before. We did not stop there, as the version that was ultimately merged in Cassandra 5 includes further improvements that reduce the need for manual configuration and make it even harder to topple.

As for the Trie project itself, how does a project like that happen end-to-end?#

This has been a long-running project for me, and is still ongoing as we speak. It started almost a decade ago, when I was a relatively fresh contributor to the project, and rather mundanely: we knew there was something to be gained if we took advantage of byte order, i.e. if we used keys that can be compared lexicographically like strings. We did not know what. Some of the more senior contributors at the time asked me to try it, as I had experience working with strings before in the context of natural languages.

This was not a small question, and it had two separate parts:

• How can we take advantage of byte order in some part of Cassandra to get a non-trivial performance gain?
• How do we introduce byte order to the data that's given to Cassandra?

I knew that the primary indexes of SSTables in Cassandra were not as efficient as they could be, so I started developing a trie-based replacement for these. To be able to make the solution generic, I also started working on ways of reinterpreting keys, so that they can become byte-ordered. The result was the trie-indexed bigtable format, i.e. the "BTI" format. Personally, I treat this format as a proof of concept of the usefulness of byte order and tries in the context of an LSM-Tree-based database like Cassandra. It brings a very noticeable improvement in query performance and improves the handling of wide partitions.

This project took about a year, and I was working on it entirely on my own until I had code to review, benchmarks to prove its efficiency as well as documentation. It was merged in DataStax's proprietary version of Cassandra In April 2017 and was delivered in DSE 6, where it has been in use as the only SSTable format for years. Five years later it was contributed to Apache Cassandra and was released (for the second time) in its version 5.

Once the concept was proven, I started working on a much bigger project with a more general approach that can be applied to all of Cassandra's primary storage and retrieval mechanisms, starting from the hardest part – memtables. The trie memtable in Cassandra 5 is the first result from this effort; like the BTI format, it landed first in the closed-source DSE 6.8, and was later contributed to Apache Cassandra 5. I have been working on this project on and off for several years already, mostly on my own with some help for short periods of time. This bigger project is now formalized as CEP-57, and its next stage will soon be up for review.

How has the adoption been since the Cassandra 5 release?#

I don't yet know, to be honest. It takes a couple of years for something new to be picked up by the community at large, and Cassandra's defaults are deliberately chosen to favour backwards compatibility over taking advantage of new features.

The BTI format and the trie memtables, however, have been in heavy use in all of DataStax database products. All customers of DSE 6 and later, Astra Classic and Serverless, as well as HCD, have relied on them for years.

What was your first computer? What got you into programming?#

For me it started with an after-school computer club in the late 80s. Like any kid I played a lot of games; at some point I saw an older student programming some simple animation which made me interested in also making stuff like that. I started reading any programming book I could find and spending even more time in that club experimenting.

The machines there were Apple II clones; I started with Basic, with some Assembler not too long after that. My first personal machine, an Intel 486-based PC, came much later after a friend and I had started writing software for a local business.

Have you ever caused an outage because of a feature someone used that you worked on?#

Even though Cassandra is difficult to break, you can cause more than enough trouble with the wrong kind of change. Last year, nearing the completion of a feature related to compaction parallelization, I added a piece of code to distribute compactions in groups that I treated as not very important. I added an assertion to let us know if the code isn't working correctly, and thought we'd quickly learn if there's something wrong with it as Cassandra is almost always run with assertions enabled.

And we did. A problem was identified and fixed, but meanwhile we had a release, and that release was used with the important assertion disabled. The result was data loss, i.e. some data was not found when requested in certain ways. Thankfully, Cassandra replicates the data and the processing, this bug wasn't deterministic enough to cause the exact same problem in all replicas, and we were able to find the data in others.

Takeaways? You can't assume any code is unimportant; you can't rely on checks that can be switched off; there are things even the best safety nets won't save you from; reducing redundancy even of secondary processes can be a risk not only to availability, but also to correctness. Things we already know, but tend to forget or push aside under pressure.

What do you think of Java?#

This is one of those questions that does not have a simple answer. There are things to hate in Java – the amount of boilerplate, the memory bloat, the hoops it makes you jump to do some things – but the JVM is a great thing, and it gives the language options that would not otherwise be possible. The garbage collection is as much a boon as it is a curse, and we too often seem to end up in a place where we need to write fragile code to compensate for having abused it too far. Any language has weaknesses and strengths, and if you can work around the former and take advantage of the latter, things will work out great. That's possible with Java, but it is not easy.

I'm very happy with the direction the latest versions of Java are taking, and am especially excited about things like virtual threads and continuations, foreign memory and vector support.

What version of Java is Cassandra on?#

The versions that are currently supported are 11 and 17, with 21 in the works. Until we drop support for Java 11, we can't use newer features in the main codebase (though subprojects like JVector do take advantage of the vector support in 21 and later).

Do you have a favorite programming language?#

To be honest, I haven't had much chance to experiment with languages lately. I liked Scala's expressivity and the way it could be adapted to become very close to different domain-specific languages. I haven't had a chance to play with Rust enough. My experience with English as a programming/prompt language has been pretty ambivalent so far, with great results on simple websites or smart home services outside of the job, and pretty terrible at anything more complex than basic unit tests or visualization of data for Cassandra.

English as a programming language… say more?#

I have had some pretty bad experiences with LLMs, and a few nice surprises. They are great, maybe even too good, at preparing things that look great and at convincing you that they solve a problem. They are not that good at actually doing it. They are pretty bad at doing it well. This works great for engagement, which means that we will have even more of this – can any AI-maker afford to optimize for anything other than engagement?

Not so great for quality. Some say that an "industrious fool" is the worst employee you can have. LLMs are extremely industrious, and at the same time foolish in very surprising ways, which are bound to get increasingly better hidden as we continue making them even more convincing.

Then there's the continuous learning problem – they are often compared to interns, but they are interns that cannot learn from the job. Even if we ignore the problem this causes for interns and more generally junior engineers, I sometimes wonder if our time is well invested in crafting instructions for something that cannot learn vs spending the same effort to teach a person?

There are tasks in which they work well; if they are not pushed too hard on us and we can afford to be careful, to use our judgement on how to use them, and, even more importantly, when not to use them, they can and will increase our productivity.

From what I understand, the Accord work in Cassandra will bring ACID transactions to Cassandra for the first time. Do I have that right?#

This is correct, Accord will bring cross-partition transactions with all the needed properties, and should be able to do it in a very efficient way, at a level of performance that scales in a manner similar to that of the eventually consistent operations of Cassandra.

I have not yet worked on or used the implementation, but I have studied the theoretical approach and its correctness enough to be pretty excited about what the implementation should bring.

Last question: Vim? Emacs? Intellij? Another editor/IDE entirely?#

IntelliJ. The tools it gives are still better than any alternative I've tried, including doing refactoring you can trust.

Thank you for your time, Branimir!#

Phil is the founder of The Consensus. Before this, he contributed to Postgres products at EnterpriseDB, cofounded and led marketing at TigerBeetle, and was an engineering manager at Oracle. He runs the Software Internals Discord, the Software Internals Email Book Club, and co-runs NYC Systems. @eatonphil

Enjoyed this article? Subscribe for unlimited access and to help us keep producing excellent articles.

Noticed a mistake? Have a question or comment? Write to the editor.