Loading...
Loading...
Browse 5 real-world technical and behavioral interview questions about Schema evolution. Review scenarios, edge cases, and architectural best practices.
Validate every record against a declared schema at the ingestion boundary, quarantine what fails instead of dropping it, treat additive changes as safe and renames as breaking, and alert on a field that has gone all-null rather than waiting for a dashboard to look wrong.
Design a safely rerunnable data pipeline by making each output partition a deterministic result of its input partition, overwriting instead of appending, and writing into idempotent sinks that tolerate retries and late events.
Additive changes with defaults are safe, removals are not, so split every removal into deprecate-then-delete with evidence that nobody reads the field. Register the schema, pick a compatibility mode deliberately, and note that backward compatibility requires consumers to deploy first.
Name the single writer first, then choose which coupling you would rather own: a shared schema couples the two teams' release calendars, while a replicated copy couples them to a staleness window and obliges someone to detect and repair divergence. Both are permanent, so pick the one your organisation can pay for.
Re-pointing traffic at the previous version is only safe if nothing else moved with it. The feature transformations, the input schema and any consumer calibrated to the current score distribution may have changed, so the unit of rollback is the model plus its features and its contract.