A cider-press co-op must reject inserts when a batch id already exists, while a later nightly sync should insert-or-replace the same items. Which Cosmos SDK pair matches those rules?
Select an answer to reveal the explanation.
Short Explanation
First rule is a bouncer—Create fails if the batch id’s already inside. Nightly sync is a librarian—Upsert puts the book on the shelf whether it was new or a replacement.
Full Explanation
Cosmos SDK write semantics differ by API. CreateItem (or language equivalent) fails if an item with the same id already exists in the partition, which enforces the cider-press co-op’s strict create-only rule for new batch ids. UpsertItem inserts when missing or replaces when present, fitting the nightly sync’s insert-or-replace reconciliation. Using that pair matches both rules without stretching unrelated APIs.
Using Upsert for the strict create-only path and Delete for the sync path inverts the semantics: Upsert would quietly replace on conflict instead of failing, and Delete removes data rather than syncing insert-or-replace. Patch does not “always insert missing items” as a general create/upsert substitute; patch updates paths on existing items and is the wrong tool for both rules as stated. Read for the first rule and Query for the second are read APIs and do not encode fail-if-exists insert or insert-or-replace write behavior.
Exam caveat: Upsert still needs the correct partition key and id; it is not a merge of arbitrary partial documents unless you supply the full intended item (use patch for partial updates). Conflict status codes on Create are expected—handle them explicitly in the create-only path. Operational check: call Create twice with the same batch id and assert the second fails; call Upsert twice and assert the second succeeds with updated fields visible on a subsequent point read.