How a foodservice distributor scaled Kafka access to 130 developers

This company is a cornerstone of America’s foodservice distribution industry, supporting approximately 250,000 restaurants and foodservice operators across the country. With 30,000 employees and more than 70 locations, the company runs an e-commerce platform built to give its customers the fastest possible ordering experience.

Kafka sits at the center of that platform, moving data from databases, data lakes, and object storage through the API that powers it. Two solution architects on the platform team are responsible for keeping that data moving reliably across a dozen product teams and roughly 130 developers, plus a QA organization spread across the US, India, and Argentina. A stalled topic or a bad offset doesn’t just slow down a developer’s afternoon, it puts the ordering experience for a quarter million foodservice operators at risk.

The challenge: scaling Kafka past CLI scripts and open-source tooling

Before adopting any dedicated tooling, the team managed Kafka by hand. “Before we had any tools, we were painfully relying on CLI scripts,” one of the solution architects recalls. “I remember needing to move an offset and thinking, okay, somebody dig out that shell script and let’s CLI this.” The other solution architect, who has been with the company and its predecessor for seven years, agrees: “Our eyes were hurting looking at that. A lot of scripts.”

The team’s first step up from CLI scripts was AKHQ, an open-source Kafka UI. It worked, but one of the architects found it limited: “I didn’t really like the interface and what it could do.” Through a conversation with Factor House co-founder Derek Troy-West, the team decided to try Kpow instead, and found it a clear improvement: the interface was fairly intuitive to navigate from the start.

As Kafka usage spread from a small platform team to a dozen product teams, access became its own challenge. The company needed developers to be able to inspect and troubleshoot Kafka themselves, without every one of them holding the keys to production. The team built a scoped, self-service permission model around Kpow: only the two solution architects hold delete access, while the rest of the organization works within defined self-service plans. That balance, self-service for the many and tight control for the few, has let the company scale Kafka access without scaling risk.

The solution: a shared dashboard for a dozen product teams

Kpow is now deployed across six to seven-plus production environments at the company, and each one is described as stable. Around 130 developers across 12 product teams have access, with 60 to 70 of them using Kpow daily. Teams use it as a dashboard to verify system state, discover dependencies, and guide the design of migrations and changes. It’s also the first stop for troubleshooting and support: reviewing messages and topics, republishing or reproducing messages, and running scheduled mutations, particularly offset changes, as part of production deployments.

Access runs through single sign-on, which matters for a team this distributed. Beyond the developers building the platform, the company’s QA organization leans on Kpow heavily from India, Argentina, and elsewhere. A consistent, SSO-backed entry point means the same tool works the same way no matter which time zone is logging in.

That same ease of use is what lets the team scale onboarding without a formal training program. New developers learn Kpow from the people already using it, in real time, on real problems.

The results: a tool intuitive enough to teach itself

The clearest sign of how far Kpow has embedded itself at the company is that nobody has to teach it formally anymore. Rather than running new hires through structured training, experienced developers walk them through real problems as they come up, live. “The leads are teaching the new people as they come, and that speaks to the intuitiveness of the tool,” one of the solution architects says. “The current users are able to, in a screen-sharing session, show their new hires how to navigate the tool and get the most out of it. They’re not just saying, look, this is what you can do. They’re saying, look, I’ve got this issue here and I’m using the tool to solve my problem, come sit by me so you can do it next time, or we can split the workload.”

That kind of organic, peer-led onboarding only works at scale if the tool itself doesn’t get in the way, and it’s what has let Kpow usage spread from a small platform team to a dozen product teams and roughly 130 developers, with 60 to 70 people in the tool on any given day, across six to seven-plus stable production environments. What started as a replacement for CLI scripts and an open-source UI has become the default way the company’s developers interact with Kafka, learned the same way most of them learned everything else about the platform: from a colleague who already knew it.

Day to day, that means lag and offset issues that used to mean digging out a shell script now get resolved from a shared dashboard, by whichever developer happens to be closest to the problem. For a platform team supporting 130 developers and an e-commerce experience used by a quarter million foodservice operators, that combination, an intuitive tool that scales itself through the team, is what keeps Kafka out of the way of the business it runs.