Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Determine whether events are facts, commands, or replicated database rows and who owns their meaning. Define compatibility for schema, semantics, ordering, retention, and privacy classification.
Establish scale assumptions
- Inventory producers, known and observed consumers, event volume, retention, and schema-change frequency. High-volume compatibility failures require replay and storage plans, not only build-time checks.
Functional and non-functional requirements
- Producers own stable semantics, consumers can upgrade independently, incompatible changes are detectable before release, and ownership remains decentralized with auditable exceptions.
High-level architecture
- Use a schema and contract registry with ownership metadata, compatibility checks, generated fixtures, lineage from runtime consumption, and CI gates. Domain councils define rules; automation approves routine additive changes.
Data model and flow
- Versioned envelopes carry type, schema, producer, event ID, occurred time, classification, and causation. Producers dual-publish only for bounded major migrations; consumers report supported versions and actual usage.
Consistency and transaction boundaries
- An event fact is immutable; corrections are new facts with explicit supersession. Adding a nullable field is structurally compatible but may still be semantically breaking if consumers infer absence.
Failure modes and recovery
- Quarantine invalid events without blocking unrelated partitions, retain replayable originals, and provide consumer lag and parse-failure alerts. Rollback preserves the older contract until all affected retention windows pass.
Security and privacy
- Classification rules block sensitive fields from unauthorized topics and require retention and regional policy. Registry write access and emergency overrides are scoped and audited.
Observability and SLOs
- Track unknown consumers, schema versions in use, parse failures, semantic quality checks, replay demand, and ownerless contracts. Notify affected owners before a proposed break.
Capacity and cost
- Dual publication and long retention are expensive; time-box them with owners and cleanup gates. Compatibility tooling costs less than recurring incident and coordination overhead.
Alternatives and trade-offs
- A central board catches nuance but does not scale; pure team autonomy externalizes breakage. Automate enforceable rules and reserve human review for semantic changes and exceptions.
Evolution and migration
- Register ownership and observe consumers first, then enable warning-only checks, generated tests, and finally CI enforcement. Migrate high-risk topics individually and publish contract health by domain.
What Staff and Principal candidates should emphasize
- Staff candidates solve both protocol and organization. They distinguish structural from semantic compatibility and design a paved road where safe changes are faster than exceptions.
Decision trade-offs
Governance
Option A
Central approval for every schema change
Option B
Federated ownership with automated compatibility gates
Recommendation:Federate routine evolution under common automated rules; escalate semantic changes and exceptions to accountable domain owners.
Major change
Option A
Mutate the existing event in place
Option B
Publish a new type or bounded dual version
Recommendation:Use a new contract for semantic breaks and keep dual publication explicitly time-bounded with consumer migration evidence.
Follow-up interview questions
- 01How do you discover consumers that never registered?
- 02Can an additive optional field break a consumer semantically?
- 03Who owns an event consumed by ten domains?
- 04How do you remove a dual-published event version safely?
Common weak answers and mistakes
- 01Relying only on schema syntax and ignoring semantic compatibility.
- 02Creating a central committee for every additive field.
- 03Dual-publishing indefinitely with no observed consumer migration.
- 04Using database row CDC as a public domain event without an ownership contract.
Interviewer evaluation rubric
Proposes a schema registry but cannot handle semantics, unknown consumers, ownership, or deprecation.
Defines versioned envelopes, compatibility checks, CI fixtures, ownership, and a safe major-version path.
Adds runtime lineage, privacy rules, federated governance, semantic review, replay, and cleanup gates.
Creates an incentive-compatible ecosystem where automation speeds safe autonomy and organizational ownership follows domain meaning.