File Upload & Scanning Pipeline  ·  View 13 of 21  ·  Runtime

Critical Flow — Initiate to First Read

Twenty-one messages, and the two that most designs leave out.

Editable source SVG draw.io All views
Client Upload API Credential minting Untrusted plane State machine Scan queue Scan worker Serving plane 1. POST /initiate size, type, scope, idempotency key 2. admission: ceiling, allow-list, quota, authz 3. mint write-only SAS for one path 4. session id + SAS (60 min) 5. PUT blocks ×N, 16 parallel, per-chunk checksum 6. GET /session which blocks landed? 7. POST /finalise block set + whole-object hash 8. assert set and hash — refuse to assemble a mismatch 9. finalised 10. enqueue once, durably, lane = interactive 11. 202 — state: scanning 12. lease, visibility = slowest permitted scan 13. read bytes (only read right it has) 14. bounded: timeout, memory, depth 12, 200× expansion 15. verdict: clean, engine + signature version 16. promote, log the transition 17. event: available 18. GET /download 19. state still available? authz still holds? 20. read-only SAS, 5 min 21. alternate: bound hit -> indeterminate, never clean Critical Flow — Initiate to First Read Message 11 is the honest one: the client is told scanning, not success. Message 19 is the one most designs omit — state and authorisation are re-checked at every credential issuance, not once at upload. v 1.0 · messages 21

The two messages that matter

  • Message 11 returns 202 with state scanning — the client is told the truth rather than success, which is what makes an honest product surface possible
  • Message 19 re-checks state and authorisation at download-credential issuance, not once at upload: without it, a revoked verdict cannot stop a reader who already has a link
  • The alternate at the end is the discipline: a bound hit yields indeterminate, never clean, which is the difference between a scanner and a rubber stamp

Decisions

  • Admission runs before any credential is minted, so every refusable condition is refused at a cost of one HTTP call
  • Finalisation asserts the block set and the whole-object hash, and the platform refuses to assemble a mismatch
  • The queue lease is sized to the slowest permitted scan for the object's class, so a long legitimate scan is never redelivered as a duplicate

Stated assumptions

  • Interactive lane, object under 10 MB: p50 2 s, p95 8 s, p99 30 s
  • Write credential 60 minutes, renewable in session; read credential 5 minutes
  • At-least-once delivery with idempotent verdict writes
◀  Data Model All views Scan Pipeline — Three Object Classes  ▶
Solution Architecture v1.0 · Microsoft Azure · Integration Platform Architecture · 2026-1013-critical-flow-upload-to-verdict