# Design a schema registry: system design interview question

> Event contracts across application versions: compatibility rules, concurrent updates, and schema access during registry failures.

Source: https://sysround.com/questions/design-schema-registry
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## 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."

## 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

## 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 probe

### 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:** Explains both compatibility directions and transitive history checks. Prevents concurrent acceptance races. Handles retry identity, replica lag, and warm versus cold client failures.
- **Staff+:** 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.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=event-schema-registry


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.