How the interviewer opens it
“Design a service that stores and versions schemas for event producers and consumers. Teams use it to change their applications without coordinating every deployment.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Schema format and subjects
- Schema identity and history
- Scale and schema size
- Read and write mix
- Latency
- Compatibility policies
- Independent deployments
- Availability and durability
- Event processing
- Access, policy changes, and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Register immutable schemas and assign subject versions.
- Enforce each subject's compatibility policy.
- Fetch the exact schema that an event identifies.
- Check proposed schemas without registering them.
Usually out of scope
- Operate the event broker.
- Validate every event payload.
- Rewrite historical events.
- Support formats other than Avro or references between schemas.
- Delete schemas.
What interviewers ask about
- Compatibility across application versions
- Producers and consumers can run different versions. A change can work in one direction but fail during replay or application rollback.
- Concurrent schema changes
- Two schemas can each pass against the same history but conflict with each other. Policy changes can also invalidate an unfinished check.
- Schema access during outages
- Events can outlive applications and registry outages. A missing schema can stop consumers even when the broker remains healthy.
Common mistakes
- Reverses the reader and writer roles in compatibility checks.
- Checks only the latest version despite a transitive policy.
- Accepts a schema after another registration changes the history used for its check.
- Uses the latest subject version to decode old events.
- Uses a normalization rule that removes defaults or aliases from schema identity.
- Treats a registry cache as the only durable copy of old schemas.
The bar by level
- Senior (L5/E5)
- Explains both compatibility directions and transitive history checks. Prevents concurrent acceptance races. Handles retry identity, replica lag, and warm versus cold client failures.
- Staff (L6+/E6+)
- Defines guarantees across policy changes, application rollback, and leader failure. Controls long-history validation cost. Explains regional write trade-offs and limits of structural compatibility.