A client came to me with deserialization failures across their Kafka consumers.

Every team owned a different service. Every service produced to the same topic. Nobody had agreed on a schema.

Service A called the field imageId. Service B called it imgId. Service C called it image_id.

All three were correct — in their own codebase. The consumer had to deal with all three.

---

Here’s the code I found in production:

image_id = (
    data.get("imageId") or
    data.get("imgId") or
    data.get("image_id") or
    "UNKNOWN"
)

And it was still returning UNKNOWN. Because someone on a fourth team had used ImageID with a capital I.

This is what happens when multiple teams share a Kafka topic with no contract. Everyone assumes their naming convention is the standard. Nobody enforces anything. The consumer pays for it.

---

The fix was Avro and Confluent Schema Registry.

One Avro schema registered per topic. BACKWARD compatibility enforced. Every producer serializes against that schema before the message reaches Kafka — if your field is named wrong, the message is rejected at produce time.

Producer (team A) ──→ Schema Registry check ──→ Kafka ──→ Consumer
Producer (team B) ──→ Schema Registry check ──→ ✗ rejected

The consumer stopped guessing. It read imageId. Always.

The result after 3 months: 0 deserialization failures, faster onboarding for new devs, and no more if/else chains that nobody wanted to maintain.

---

I built a working demo of this exact scenario — chaos world first, then the fix, then a script that tries to sneak in the wrong field name and gets rejected.

github.com/skayikci/kafka-real-world-demos

Docker Compose, Avro schemas, Schema Registry, the whole stack. Run it in 5 minutes.