What does auto.register.schemas do, and why might you disable it on producers in production?

## The flag `auto.register.schemas` is a `KafkaAvroSerializer`/`AbstractKafkaSchemaSerDe` property, **default true**. On the producer's first send of a record type, the serializer: 1. Computes the subject (default `<topic>-value`). 2. If the local writer schema isn't already registered under that subject, **registers it** (HTTP POST) and receives a global ID. 3. Embeds that ID in the wire format. Subsequent records reuse the cached ID — the serializer maintains an in-memory schema→ID cache so there isn't a registry round-trip per message. ## Why true is fine in dev, risky in prod In development, auto-registration is a great quick-start: deploy a producer, schemas appear automatically. In production it means **any application deploy can mutate the shared schema catalog**. Problems: - **No review gate.** A code change to a generated class silently registers a new schema version. - **Compatibility drift.** Registration is still subject to the subject's compatibility mode, but if that mode is permissive (e.g. NONE), an incompatible schema can land and break consumers. (Compatibility modes themselves are a sibling topic; the governance concern here is *who* registers.) - **Drift between environments.** Schemas registered ad hoc in one cluster differ from another. ## The production pattern Many teams set: ``` auto.register.schemas=false use.latest.version=true ``` - `auto.register.schemas=false` — the producer will **not** register; if the schema isn't already present it fails fast. Registration is instead done by a **governed pipeline**: the Confluent `schema-registry-maven-plugin` (`register`/`test-compatibility` goals), a Gradle equivalent, or direct API calls in CI/CD, with PR review. - `use.latest.version=true` — instead of using the producer's locally-compiled writer schema, the serializer fetches and uses the **latest registered version** of the subject. This centralizes which schema is authoritative and prevents a slightly-stale local class from registering a competing version. ## Caching and performance The serializer/deserializer cache schemas and IDs in memory (`max.schemas.per.subject`, default 1000) so registry calls amortize to roughly one per new schema, not one per record. This matters at high throughput — a registry outage after warm-up may not immediately break already-cached schemas, but new schema IDs (producer) or unseen IDs (consumer) will require a live registry. ## Deserializer side The **deserializer never auto-registers** anything — it only resolves IDs to schemas by reading from the registry. So `auto.register.schemas` is exclusively a producer governance concern. ## Principal-level framing Treat the schema registry as a **governed shared contract store**, not a side effect of deploys. `auto.register.schemas=false` + CI registration + compatibility checks makes schema evolution an explicit, reviewable change — the same discipline you'd apply to a database migration.