What's the difference between a 'weak schema' approach and a 'strong schema registry' approach to versioning events within an event-sourced store, and what does each cost you?

## The structural question Every event-sourced system has to answer a structural question before it writes a single event: how strictly is the shape of an event enforced, and by what mechanism? 'Weak schema' and 'strong schema registry' are the two ends of that spectrum, and the choice shapes how schema evolution mistakes get caught — **early and cheaply, or late and expensively.** ## How each one actually works - **In a weak-schema system**, events are typically serialized as JSON carrying a `type` name and a `version` number, but no external authority validates that a given payload actually conforms to any declared shape. The application code that writes the event decides what fields to include; the application code that reads it decides what to expect, and if those disagree — a field is misspelled, a type doesn't match, a required field is missing — nothing catches it until deserialization fails or, worse, silently produces wrong values at read time, potentially in production, potentially months after the bad event was written. Compatibility is entirely a matter of team discipline and testing; there is no gate. - **In a strong-schema-registry system**, the pattern popularized by Avro and Protobuf usage with Kafka via tools like Confluent Schema Registry, every event type has a formally registered schema per version, and the registry enforces a declared compatibility mode — backward, forward, or full — at the moment a writer tries to publish a new schema version. If a proposed schema violates the compatibility rule, say removing a field that lacked a default, the registry rejects the registration outright, before any event using that broken schema can ever be produced. ## Why both patterns exist The reason both patterns exist, rather than one clearly dominating, is that they optimize for different failure timing and different organizational scales. 1. **Weak schema exists because most systems start small**, with one team owning both writers and readers, where the overhead of a registry and a registration workflow is pure friction relative to the risk — you can just be careful, write good upcasters, and test them, because a mistake's blast radius is contained to your own team. 2. **Strong schema registries exist because at larger scale**, with many independent teams reading and writing the same event types on different deploy schedules, informal discipline doesn't scale: nobody can review every other team's event changes for compatibility by hand, and a single incompatible change from one team can silently break a consumer owned by a completely different team. ## The trade-off The trade-off is symmetric and real on both sides. - **Weak schema costs nothing in tooling or process** and stays maximally flexible, but the cost is deferred and often more expensive: incompatible changes are caught by production failures, not a pre-write gate, and by the time you notice a consumer has been silently defaulting a missing field for two weeks, you may need a data-repair job on top of the schema fix. - **Strong schema pays the cost upfront and continuously:** someone has to run and operate the registry, every schema change goes through a registration step, and the enforced compatibility mode can feel rigid when a genuinely necessary breaking change now needs a conscious version bump and coordinated consumer upgrades rather than a quiet rename. ## Failure modes In production, weak-schema failure modes look like: - a typo'd field name shipped without anyone noticing until a downstream projection silently stops updating; - two teams independently 'fixing' the same event type in incompatible ways because there's no single source of truth for the current schema; - and upcasters written reactively, after a break is discovered, rather than proactively. Strong-schema-registry failure modes look different: - a team blocked mid-incident because a legitimately necessary breaking change is rejected by the compatibility mode with no fast path; - the registry itself becoming a bottleneck or single point of failure if not made highly available; - and teams gaming the system by registering overly permissive schemas, like a top-level catch-all blob field, specifically to bypass enforcement, which reintroduces weak-schema risk inside a nominally strong-schema system. A well-known real-world reference is Confluent Schema Registry's compatibility modes, `BACKWARD`, `FORWARD`, `FULL` and their transitive variants, applied to Avro schemas on Kafka topics — the most widely deployed version of exactly this pattern, though the same registry-and-enforce idea shows up in any platform wanting publish-time safety instead of runtime discovery.