Jump to a problem, path or page
Jump to a problem, path or page
Updates as you edit. Run the review to record it; passing every check completes the problem.
Not yet passed: Client responsibility
Add Client and define its responsibility.
Not yet passed: API service responsibility
Add API service and define its responsibility.
Not yet passed: Database responsibility
Add Database and define its responsibility.
Not yet passed: Canonicalizer responsibility
Add Canonicalizer and define its responsibility.
Not yet passed: Compatibility checker responsibility
Add Compatibility checker and define its responsibility.
Not yet passed: Schema cache responsibility
Add Schema cache and define its responsibility.
Not yet passed: Client → API service
A directed path must connect Client to API service. Arrows represent requests, dependencies, or event flow.
Not yet passed: API service → Canonicalizer
A directed path must connect API service to Canonicalizer. Arrows represent requests, dependencies, or event flow.
Not yet passed: API service → Compatibility checker
A directed path must connect API service to Compatibility checker. Arrows represent requests, dependencies, or event flow.
Not yet passed: API service → Database
A directed path must connect API service to Database. Arrows represent requests, dependencies, or event flow.
Not yet passed: API service → Schema cache
A directed path must connect API service to Schema cache. Arrows represent requests, dependencies, or event flow.
Not yet passed: What does backward compatibility mean in this exercise?
Not yet passed: How should a new required field without a default affect old data?
Not yet passed: How should event payloads identify their contract?
Not yet passed: API and data model notes
Write at least 80 characters describing concrete operations, inputs, outputs, state and errors. This check measures completeness, not semantic correctness.
Not yet passed: Trade-offs and failure cases
Write at least 80 characters about alternatives, failure handling and edge cases. Review the reasoning yourself using the reference discussion.
Rule-based educational feedback. Notes are checked by length only; topology checks confirm directed reachability. These checks do not validate semantics, latency, reliability or every valid design.
Register canonical immutable schema documents with explicit subject/version relationships and a restricted reader/writer compatibility model. Atomic version-checked registration prevents concurrent changes bypassing policy. Define the supported record schema and reader defaults/unknown-field behavior. Validate and canonicalize schemas, excluding only semantically irrelevant formatting under a versioned canonicalization rule. For backward checks, ensure the new reader can obtain every required field from each selected old writer or a valid default. For forward checks invert reader/writer roles; reject unsupported type changes conservatively. Under a subject transaction verify expected latest version and compatibility against the configured latest/transitive set. Insert or reuse an immutable schema ID and append the new subject version. Events carry schema ID. Consumers cache immutable schemas by ID with bounded memory; unknown IDs fail explicitly or retry registry lookup rather than decode under the latest schema. Authorization scopes subjects and administrative policy changes.
There is no single correct diagram. Explain where yours differs and which requirement justifies it.