Systems | Development | Analytics | API | Testing

You're three hours into debugging a stalled Kafka consumer. The lag is climbing. Customers are complaining. Your logging doesn't show anything useful, and changing the log level requires a deployment approval that won't come until tomorrow morning. Sound familiar? If you're operating Apache Kafka at scale, that sinking feeling when a consumer group stops progressing, and you're left playing detective with insufficient clues.

Devoxx Poland 2025 felt different. Not because of revolutionary new frameworks or another "this changes everything" moment, but because of what didn't happen. The conference had an unusual dose of pragmatism, skepticism, and – dare we say it – common sense. Maybe it's because developers are asking the right questions: "Does this solve a problem?" and "What happens when this inevitably breaks?" Here's what emerged from the sessions we watched, and the people we spoke to.

Let's talk about a problem that might sound simple but gets complex quickly: copying data from one Kafka cluster to another. As our Kafka usage grows, many of us find ourselves managing multiple clusters and needing to share data between them. Or worst still, sharing data to an external cluster. During a London meetup, we explored why this happens, what existing solutions offer, and why we decided to build our own Kafka replicator. Here's what we learned.