Open-source Spring Boot starter for fail-fast Kafka Schema Registry contract validation, looking for feedback

[u/CartographerWhole658]

I’ve been working on a small open-source Spring Boot starter to solve a problem I’ve encountered with Kafka-based applications: detecting Schema Registry contract problems before the application starts serving traffic.

The idea is simple: during Spring Boot startup, the starter validates the configured Schema Registry subjects, expected compatibility mode, and the application's local schemas against the latest registered versions.

If a subject is missing, the compatibility policy is not what the application expects, or a schema is incompatible, startup fails.

Current support includes:

• Avro, JSON Schema and Protobuf
• BACKWARD, FORWARD, FULL and transitive compatibility modes
• Confluent Schema Registry / Confluent Cloud authentication
• bounded retry/backoff for temporary registry failures
• Spring Boot Actuator visibility
• Spring Boot auto-configuration

I also created a separate E2E demo using real Kafka + Schema Registry. Its CI verifies a real producer → Kafka → consumer round trip, a backward-compatible schema evolution, and an intentionally breaking schema that must be rejected at application startup.

Source:

https://github.com/mathias82/spring-kafka-contract-starter

E2E demo:

https://github.com/mathias82/spring-kafka-contract-demo

I’m interested in feedback from Java/Kafka developers: would you find startup-time contract enforcement useful, or do you prefer keeping this entirely in CI/CD?

I’d also be interested in edge cases you would expect a library like this to handle before considering it for a production application.

[u/Torutofu_Raeva]

startup time is where i'd want it, ci can't really know what's registered in the cluster you're actually deploying to. the edge case i'd worry about is the registry being unreachable at boot, killing the pod for that is its own outage.

[u/CartographerWhole658 → u/Torutofu_Raeva]

Thanks, that’s a good point. That’s also why the starter uses bounded retry/backoff rather than failing immediately on a transient registry error.  I agree there’s an important distinction between a contract violation and the registry simply being unavailable. A missing/incompatible schema should fail startup, while temporary connectivity issues probably need a configurable policy (fail-fast vs warn/continue after retries). I’ll look at making that distinction more explicit. Thanks for the feedback!

[u/Torutofu_Raeva → u/CartographerWhole658]

yeah, fail-fast on a bad schema and retry on can't-reach-the-registry is the split that actually matters in prod