Lesson 14 · Senior Kafka practice

Schema evolution and event contract safety

How to reason about changing JSON events safely when the repo does not rely on schema registry or Avro on the wire.

Your win: explain why event-schema changes are really distributed-contract changes, and how to talk about compatibility discipline in a JSON-based Kafka system.

In plain English Plain English: changing an event shape is easy to code and easy to underestimate because the producer and consumer are not deployed together.

Why this becomes a senior problem

Kafka decouples producers and consumers in time. That is one of its biggest strengths. It also means an event contract can live longer than one deploy. A producer can start writing a new payload shape while an older consumer is still reading the old assumptions.

That is the whole senior point here. Event evolution is not just a code-change problem. It is a runtime compatibility problem.

The contract rule An event is not just internal data. It is a distributed contract between code that may upgrade at different times.

Why JSON flexibility cuts both ways

In a schema-registry-enforced environment, some compatibility discipline is checked for you. In this repo, payloads are JSON. That makes change easier to ship, but it also makes it easier to break something quietly if engineers treat payload changes like local refactors.

The safest changes are additive and tolerant. The dangerous ones are semantic breaks: removing fields consumers still need, changing meanings, or assuming every reader upgraded at the same time.

Backend use case Because this repo uses JSON payloads on Kafka rather than schema-registry-enforced wire contracts, compatibility discipline must be part of how engineers design and review event changes.
Common mistake Treating an event-shape change like a local refactor because the producer and consumer code live in the same monorepo.
Read this next

Revisit the repo map and design docs together

Use the repo map to confirm the wire shape is JSON, then connect that reality back to Kafka’s decoupling model.

→ Repo Kafka map
→ Apache Kafka design docs

Check yourself (from memory)

Q1. Why are event-schema changes a senior Kafka concern?

Event contracts outlive one deploy and cross service boundaries, even in one repo.
What is the safest mental model for evolving Kafka event payloads?
recall, then click to reveal
Treat them as distributed contracts: prefer additive, tolerant changes; avoid semantic breaks unless rollout and compatibility are explicitly managed.
Want me to turn this into an “is this event change safe?” review drill? Ask me.

Sources. Repo Kafka map; Kafka design docs; curated course resources.