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 falling short of the company's performance expectations. And its replacement, though less well-known, proved to be more aligned with their philosophy: NATS.

To understand this strategic shift in depth, we interviewed Elena Alonso, Head 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 for years across many deployments. But over time, we began to notice it wasn’t meeting our speed and efficiency needs. We were seeing latency issues in critical flows, especially when nodes hit peak loads. For a cloud-native company like DIVERSITY, with services that 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 technological pillar like Kafka isn’t a minor decision. What triggered this reassessment?

Sergio Ceballos: What initially seemed like a resource-tuning issue turned into a structural problem. Kafka was holding us back. We had very high latency even in internal flows, and its resource consumption was misaligned with our vision of efficiency. For a cloud-native company like DIVERSITY, with services depending on real-time event streaming, that’s unacceptable. When we ran internal benchmarks with NATS, we saw real improvements: faster responses, lower CPU and memory usage, and a much simpler operational architecture.

Elena: And when did this analysis begin?

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

The proof of concept: NATS begins to stand out

Elena: What convinced you during the proof of concept?

Sergio: Two things: JetStream and the system’s lightweight nature. JetStream, NATS’ persistence layer, proved we could have message retention without the high disk usage we had with Kafka. And secondly, NATS better suited our cloud-native approach, especially within Kubernetes.

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

The migration: from physical to containerized

Elena: How was the migration process? It sounds ambitious.

Sergio: Honestly, it was very agile. Since we don’t have legacy systems, we were able to move fast. In total, it took three months from PoC to production. One month was for the proof, and the following two for a gradual 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, shifting the team’s mindset. We had years of Kafka experience—partitions, brokers, zookeepers... NATS is a different world. Simpler, yes, but it also requires a good understanding of modern pub-sub workflows. The main challenge was cultural: changing the team’s mentality. Many were used to Kafka’s tools and commands. But NATS’ documentation is excellent, and within two weeks, most of the team was operating normally.

Tangible results: consumption, containers, and sustainability

Elena: And what about results in production? Was it worth it?

Sergio: Absolutely. We saw between 40% and 80% less average CPU and RAM usage per node. Before, we needed 10 Kafka nodes on bare-metal; now we only need 3 NATS nodes on 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’ native mutual TLS (mTLS) for client-server communication.
• IOPS and storage consumption dropped by 50%.
• And perhaps most significantly: by lowering the energy load of our servers, we reduced our carbon footprint by 2.5 tons per year.

The current architecture: Kubernetes as the core

Elena: What can you tell us about the current architecture, without disclosing sensitive details?

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

Additionally, we’ve set up a tenant-level security layer, with unique certificates managed by our cloud identity platform. The entire system is connected to 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 when strict ordering and retry guarantees are needed. But for cloud-native companies focused on efficiency, scalability, and simplicity, NATS has a clear edge. If you’re starting from scratch, there’s no reason to make things more complicated.

What we learned as a technical team

Elena: What lessons did you take from this as a CTO?

Sergio: That you shouldn’t get married to technologies. Even the big names can become bottlenecks. And that a flexible, container-based architecture lets you evolve faster. The move from Kafka to NATS was a technical decision, but also a strategic one: it allowed us to be more agile, more sustainable, and more 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 cases for clients with hybrid deployments. Plus, with NATS we now have a much more agile foundation to build new cloud-native services.

A cloud-native company is constantly reinventing itself

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

Sergio: Completely. At DIVERSITY, we’re always looking to optimize—not just for ourselves, but for our clients too. This type of migration allows us to be more efficient and pass on those benefits in our solutions: from our artificial intelligence platforms, to our cloud and bare-metal infrastructure, and our consulting and event streaming services.

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

Are you considering modernizing your event infrastructure?

DIVERSITY helps organizations scale with confidence, offering secure and high-performance cloud infrastructure tailored for modern workloads. From AI-ready GPU servers to fully managed databases, we provide everything you need to build, connect, and grow — all in one place.

Whether you're migrating to the cloud, optimizing your stack with event streaming or AI, or need enterprise-grade colocation and telecom services, our platform is built to deliver.

Explore powerful cloud solutions like Virtual Private Servers, Private Networking, Object Storage, and Managed MongoDB or Redis. Need bare metal for heavy workloads? Choose from a range of dedicated servers, including GPU and storage-optimized tiers.