In the tech world, few decisions are as critical as changing the backbone of a company’s messaging infrastructure

Yet that’s exactly what DIVERSITY, a cloud-native company with a global presence and data centers in Europe and the Americas, decided to do. The reason? Kafka, a market standard, was no longer meeting the company’s performance expectations. And the replacement, though less well-known, proved to be a better fit with their philosophy: NATS.

To understand this strategic shift in depth, we interviewed Elena Alonso, Director of Business Development and Marketing, and Sergio Ceballos, CTO of DIVERSITY.

Elena Alonso: Why did you decide to reconsider the use of Kafka?

Sergio Ceballos: Kafka served us well for years in many deployments. But over time, we began to notice that it didn’t meet our speed and efficiency needs. We had latency issues in critical flows, especially when nodes hit peak loads. For a cloud-native company like DIVERSITY, where services depend on real-time event streaming, that’s unacceptable.

Kafka was holding us back

Elena Alonso: Sergio, in a cloud-native organization like ours, changing a foundational technology like Kafka is no small decision. What drove this review?

Sergio Ceballos: What initially seemed like a resource tuning issue turned out to be a structural problem. Kafka was holding us back. We had high latencies even in internal flows, and its resource consumption didn’t align with our vision of efficiency. When we ran internal benchmarks with NATS, we saw real improvements: faster response times, lower CPU and memory usage, and a much simpler operational architecture.

Elena: When did this analysis start?

Sergio: Officially, about four months ago. The first month was an intensive proof of concept in controlled environments. We saw that not only was NATS more efficient, but it also let us redesign our infrastructure to better align with Kubernetes. We stumbled upon NATS almost by curiosity. A couple of our system architects were evaluating it for a client. What caught our attention was how lightweight it was—and the results were surprising, particularly the much smoother learning curve for our teams.

The Proof of Concept: NATS Stands Out

Elena: What convinced you during the proof of concept?

Sergio: Two things: JetStream and the system’s lightness. JetStream, the persistence layer of NATS, showed us we could have retention without the high disk usage we experienced with Kafka. And second, NATS fit much better with our cloud-native approach, especially in Kubernetes.

In fact, we moved from Kafka deployed on bare-metal nodes with custom configurations to three NATS pods orchestrated by Kubernetes. That alone gave us more elasticity and less dependence on fixed infrastructure.

The Migration: From Physical to Containerized

Elena: What was the migration process like? Sounds ambitious.

Sergio: Honestly, it was very agile. Since we don’t have legacy systems, we could move fast. It took a total of three months from PoC to production. One month for the PoC, and the next two for a progressive transition. We migrated several internal pipelines, adapted our microservices’ subscriptions, and designed a new observability layer over Prometheus and Grafana tailored for NATS.

Elena: And the challenges?

Sergio: Mainly, the mental shift for the team. We had years of experience with Kafka—its partitions, brokers, zookeepers… NATS is a different world. Simpler, yes, but it requires a good understanding of modern pub-sub workflows. The biggest challenge was cultural: changing the team’s mindset. Many were used to Kafka’s tools and commands. But NATS documentation is excellent, and within two weeks, most of the team was operating comfortably.

Tangible Results: Consumption, Containers, and Sustainability

Elena: And in production? Was it worth it?

Sergio: Absolutely. We saw a 40% to 80% reduction in average CPU and RAM usage per node. We went from 10 Kafka nodes on bare metal to just 3 NATS nodes in Kubernetes. This allowed us to containerize the system, which brought several benefits:

  • We reduced maintenance by 30% for our SRE and DevOps teams.
  • Simplified security using NATS’s native client-server mutual TLS certificates.
  • Cut IOPS and storage usage by 50%.
  • And perhaps most importantly: by lowering server energy consumption, we reduced our carbon footprint by 2.5 tons per year.

Current Architecture: Kubernetes at the Core

Elena: Can you share something about the current architecture, without disclosing sensitive information?

Sergio: Of course. Today, we have a 100% Kubernetes-native architecture. Each NATS instance runs as a container in a StatefulSet. JetStream operates in clustered mode, and we use persistent volumes from a Ceph cluster, giving us flexibility and resilience.

We’ve also implemented tenant-level security, with unique certificates managed by our cloud identity platform. The entire system connects with our internal AI and event-processing microservices, making it the backbone of our event-driven solutions.

Does Kafka Still Make Sense for Some Companies?

Elena: Many clients use Kafka as the standard. Do you think NATS is for everyone?

Sergio: Not necessarily. Kafka has valid use cases, especially where strict guarantees of ordering and retries are required. But for cloud-native companies focused on efficiency, scalability, and simplicity, NATS has a clear advantage. If you’re starting from scratch, there’s no reason to complicate things.

Lessons Learned as a Tech Team

Elena: What’s your takeaway as CTO?

Sergio: Don’t get married to technology. Even big names can become bottlenecks. And a flexible architecture, container-based, lets you evolve faster. The shift from Kafka to NATS was a technical decision, but also a strategic one: it allowed us to be more agile, sustainable, and secure. We’ll continue expanding its use—not just in traditional event streaming. We’re exploring integrations with AI systems for real-time processing and edge computing scenarios for clients with hybrid deployments. Also, with NATS, we now have a much more agile foundation for building new cloud-native services.

A Cloud-Native Company Is Constantly Reinventing Itself

Elena: To wrap up, how does this change align with DIVERSITY’s vision?

Sergio: Completely. At DIVERSITY, we constantly strive to optimize—not just for ourselves, but for our clients too. Migrations like this allow us to be more efficient and pass on that value in our solutions: from our AI platforms, to our cloud and bare-metal infrastructure, and our consulting and event streaming services.

Kafka was a great ally for years, but at this stage, NATS offers exactly what we’re looking for: speed, simplicity, security, and sustainability.

Considering modernizing your event infrastructure?