Section 2: Old Run or New Run, Never Both - Requirements (Functional & Non-Functional)
Executive Summary: This section turns Section 1's answers into a contract. Eight functional requirements split between producers (schemas, bulk operations, rollback, human edits) and consumers (reads, a search DSL, offline export). Four features are ruled out with reasons. The non-functional requirements put numbers on latency, freshness, availability, durability, rollback and isolation. One asymmetry carries the section: a run can be late, but never mixed. The contract then decides four design choices before any arithmetic.
The clarifications are done. The interviewer leans back: "So what exactly are you committing to?" "Searchable annotations, fast" is not a commitment. "Priya's intersection query on Night Heist returns in 300 ms at p99" is. Every line you write now should be something a test could check.
The Functional Contract
Two kinds of customer, two halves of the contract: producers write in bulk, consumers read and search.
| # | Requirement | Notes |
|---|---|---|
| FR1 | Register and version annotation schemas | Teams self-serve. Minor versions are additive only; a breaking change is a new major version |
| FR2 | Run an operation: start, write batches, finish with a declared count, cancel | The unit of a bulk write. Its annotations become visible together, or not at all |
| FR3 | Roll back a scope to its previous run | Scope = (entity, schema, producer) |
| FR4 | Create, edit and delete single annotations | For human taggers. Every edit is a new version; a delete is a tombstone version |
| FR5 | Read an annotation by id, optionally at a given version | |
| FR6 | Read an entity's annotations by schema and media-time range | "Everything char-detect found in Night Heist between 41:00 and 42:00" |
| FR7 | Search with one query DSL | Field filters, text, temporal overlap and intersection, spatial boxes, semantic similarity. One title or the whole catalog |
| FR8 | Export annotations for offline training and analytics | Bulk readers never touch the online stores |
The diagram groups them by who calls them.
Interviewer: "Why is rollback its own requirement? If v4 is bad, re-run v3."
You: "Re-running v3 means GPU time and re-ingesting everything, maybe hours. Meanwhile editors see wrong results. So I keep the old run around, and rolling Night Heist back from char-detect v4 to v3 is a switch, not a recompute."
Interviewer: "And FR4 says every edit is a new version. Why not update the row?"
You: "A tagger fixing a label needs to know nobody changed it first, so an edit carries the version it read and fails if that's stale. And Section 1 said corrections must survive re-runs, so the next model run can't quietly overwrite them."
Quick check before moving on:
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson