A city 311 bus starts shipping optional JSON fields for newly added service categories while older mobile apps still consume the topic. What ingestion design best tolerates that schema evolution?
Select an answer to reveal the explanation.
Short Explanation
New optional fields are like extra stickers on a form—older clerks can still read the blanks they know. Design consumers to skip unknown properties instead of crashing. That is how civic event buses evolve without a citywide lockstep upgrade.
Full Explanation
Additive optional fields with forward-compatible consumers are the durable pattern for municipal schema evolution on a shared 311 bus. When producers introduce new service-category attributes, older mobile apps continue to parse the keys they understand and safely ignore unknown properties, so the topic keeps flowing without a citywide lockstep release. That design matches how civic event streams actually change: categories and attributes appear over time while many agencies still run prior app versions.
Rejecting every event that fails an original fixed schema turns routine enrichment into an outage for the producer and for every healthy consumer still reading known fields. Nightly rewrites of historical topic messages to freeze one layout destroy provenance, burn compute, and still fail the moment the next optional field appears. Forcing every consumer to upgrade on the same day before producers may add fields creates brittle release coupling across vendors and departments that rarely share a single change window.
Exam caveat: “ignore unknown properties” is not a license to skip validation of required business keys, types, or authorization on known fields; tolerance applies to additive unknowns, not to corrupted or unauthorized payloads. Operational check: publish a canary event with one new optional property into a non-production topic, confirm a legacy consumer processes the known keys without error, and verify newer consumers read the new field before promoting the producer change.