Most teams adopt Kafka (or Confluent, or any event-streaming platform) because they've been told it will make their systems "real-time" and "decoupled." Both promises are true in the way a gym membership makes you fit — only if you actually change the underlying behavior, not just swap the tool underneath it. I've now led enough of these migrations, across both greenfield platforms and 15-year-old integration estates, to have a consistent view: the hard part was never the broker.
The topic-per-consumer trap
The single most common failure mode I see is teams treating Kafka as a faster version of the point-to-point messaging they already had. A team needs data from another team, so they get a topic created, the producer starts publishing to it, and the consumer subscribes. This works fine for the first six months. By month twelve, you have forty topics that are really just RPC calls with extra latency and no schema enforcement, and nobody remembers which topic feeds which downstream system.
Event streaming earns its complexity when events are modeled as facts about the business, published once, and consumed by however many systems find them useful — not as directed messages between two known parties. If you're naming a topic team-a.notify-team-b, you've built a queue with delusions of grandeur. A better test: could a system you haven't thought of yet consume this topic usefully, without asking the producer to change anything? If the answer is no, you've modeled an RPC call, not an event.
Schemas are the actual API
Every integration platform I've worked on — webMethods, Boomi, now Kafka-based platforms — eventually converges on the same lesson: the contract between systems matters more than the protocol. With REST APIs this is obvious, because the contract is visible in every request. With event streams it's invisible until it breaks, usually in production, usually for a consumer team that didn't know the producer had shipped a change.
Schema registries (Confluent Schema Registry, or an equivalent) aren't optional infrastructure for a serious platform — they're the thing that makes event streaming safe to scale past two teams. The rule I hold my teams to:
- Every topic has an owning team and a registered schema. No exceptions, no "we'll add it later."
- Schema evolution is additive-only by default. New optional fields, yes. Renaming or removing a field is a new topic version, with a deprecation window, not a silent breaking change.
- Consumers validate against the schema at the boundary, not three services downstream where the failure is unrecoverable and undebuggable.
None of this is Kafka-specific. It's the same discipline good API teams already apply to REST contracts — it's just less obvious that you need it, because nobody's browser dev tools show you a 400 error when an event stream silently changes shape.
"Real-time" is usually the wrong goal
When a business stakeholder asks for "real-time data," what they almost always mean is "I don't want to wait for tomorrow's batch job." That's a latency requirement measured in minutes, not milliseconds. Chasing genuine real-time (sub-second, streaming joins, exactly-once processing across services) for a use case that actually needed "within the hour" is how platform teams burn a year building infrastructure nobody asked for.
Before committing to a streaming-first design for a given use case, I ask three questions:
- What decision changes if this data arrives in 5 seconds instead of 5 minutes?
- Who is consuming this, and do they need the stream, or do they need the current state derived from it?
- What does correctness look like under reordering, duplication, and late-arriving events — and does the consumer actually need to handle that, or can a materialized view absorb it for them?
That third question is the one teams skip. A well-built streaming platform usually ends up doing as much work maintaining materialized views and CDC-derived read models as it does moving raw events, because most consumers don't want a stream — they want an always-current answer to a question, and a stream is just the mechanism that keeps it current.
What actually makes these platforms succeed
Across every one of these programmes, the platforms that succeeded had less to do with the technology choice and more to do with three things holding steady:
- A platform team that owns operability, not just the initial rollout — monitoring consumer lag, alerting on schema violations, and treating topic sprawl as technical debt to be actively managed, not an emergent property nobody's responsible for.
- Producers who treat their events as a public product, documented and versioned, because someone they've never met is depending on them.
- A default bias toward fewer, well-modeled event types over one topic per use case — resisting the topic-per-consumer trap even when it would be faster this sprint.
None of that shows up in an architecture diagram, which is exactly why it's the part that gets skipped under deadline pressure — and exactly why it's the part I spend most of my time on now.