Storage Tiering Service  ·  View 10 of 31  ·  3 · Structure

Integration Surface

Three inbound interfaces, three outbound, and which of them a user's read actually waits on.

Editable source SVG draw.io All views
Callers File service Upload service Export and eDiscovery Platform Storage Tiering Service resolve · decide · move · recall Dependencies Ceph RGW tiers EOS + CTA Records management Resolve · gRPC Register Recall jobs S3 · STS Tape REST holds Integration Surface — Every Interface External / third party Application we own synchronous event / async Only Resolve and the GET after it are on a read path. ML pipelines call Resolve as non-promoting; identity, keys and the finance ledger are on view 01. v 1.0 · owner Storage Platform Architecture · date 2026-09

Contracts

  • Resolve (gRPC): object key and declared reader class in; location, byte range, key id and recall class out. Idempotent and cacheable for 60 seconds. It never returns a tier name to a product surface.
  • Register (gRPC): called at upload commit with the tenant and an object class. The ingest placement comes from a compiled table, so an archive-bound backup is written to its tier once instead of to hot and then moved.
  • Recall jobs (REST): a set of objects, an authority and a budget; a job handle with an ETA back within three seconds.

Standard protocols at the seams

  • S3 API and STS towards Ceph; the WLCG Tape REST API towards EOS and CTA, which dCache also implements. Either storage product can be replaced without the service changing its model.
  • Hold events arrive as idempotent messages with the records-management reference, so a replay cannot create a second hold.

Omitted here

  • Identity, keys and the finance ledger (view 01), and Ceph bucket notifications feeding the reconciler (view 30).