Embedding Pipeline Service · View 13 of 22 · Runtime
The atomicity point
- Message 15 is the architecture: the new version becomes visible only once every chunk of it is indexed. Until then retrieval keeps returning the previous version.
- A half-reindexed document is strictly worse than a stale one — it matches on old wording and new wording at once, and no reader can tell which they are looking at.
- The ingest 202 at message 5 is returned on durability in the change log, not on being indexed. The accept path never waits on a GPU.
Where the cheapness comes from
- Messages 7 to 10: the ledger is asked what the previous version's chunks were, and the diff reduces 41 chunks to 3.
- Message 12: those 3 are looked up in the vector cache first. On a reverted edit all 3 are hits and no inference happens.
- Delivery from the change log is in order per document (keyed partitioning), so two rapid edits cannot race into an older version winning.
Assumptions
- 41 chunks is around the p75 document; the mean is 12 and p99 is 310.
- Interactive lane p50 30 s end to end for this flow, p99 10 min (stated assumption).
