Multi-broker replication protects against a node going down. It does nothing when the real threat is a bad deploy that corrupts messages, a misfired script that empties a topic, or a schema change that silently breaks every downstream consumer. In those scenarios, redundancy just means the bad data exists in three places instead of one.
Closing that gap is what brought Irori and Kannika together. We are excited to announce a partnership where we together brought point-in-time Kafka recovery to a Swedish public sector customer.
Why the partnership
The customer needed the ability to restore a specific topic to exactly how it looked at a specific moment, not the nearest snapshot, not a full replay from offset zero. That requirement led Irori to Kannika Armory.
Two things made the decision straightforward.
- The first was precision. Kannika Armory restores a specific topic to a specific timestamp or offset, the difference between a scalpel and a sledgehammer when something has actually gone wrong.
- The second was fit. Kannika Armory ships as a Kubernetes Operator with its own Custom Resource Definitions, so backup, storage, credentials, and restores are described as plain Kubernetes manifests. That meant no niche tooling to learn and no gap in the customer’s existing GitOps workflows, everything is versioned as code and deployed the way everything else already is. The declarative model also removes a category of misconfiguration risk, since there is no manual setup step to get wrong.
Beyond the tool itself, the Kannika team has been directly involved throughout the engagement. Kannika’s co-founders joined support conversations personally, and the company guides customers through the public roadmap directly, an approach that made the relationship feel less like a vendor purchase and more like a partnership.
The case we solved together
“Traditional disaster recovery gives you some peace of mind, but point-in-time restore is what actually changes how you work day to day,” said Jacob Danielsson, Kafka Engineer at Irori, who was part of the implementation. “We can replay events without doing manual offset math. We just tell it the moment we want and it handles the rest.”
In production, the setup now runs as continuous, near-real-time backups of production topics, configured once as code. Retention is handled automatically through the same manifests, so nobody has to remember to clean up old backups. Because it runs as another Operator inside the cluster, it behaves like everything else in the stack.
“From our initial conversations with Irori, there was an immediate connection; it felt as though we had already been working together for years.”
said Wout Florin, co-founder of Kannika.
Looking ahead
If there’s one thing we’d tell other teams running Kafka, it’s that backup and restore deserves to be treated as real infrastructure, not something you bolt on later.
About Irori
Irori is a Stockholm-based tech consultancy operating through three specialized subsidiaries, Irori Integration, Irori Platform, and Irori Security, delivering event-driven architecture, platform engineering, and security expertise to enterprise and public sector clients across Sweden.
About Kannika
Kannika builds Kannika Armory, a Kubernetes-native backup and restore solution for Apache Kafka, giving teams point-in-time recovery for production event streams.
