Leaderboard & Counting Service  ·  View 18 of 21  ·  Operations

Projection Lifecycle

Declared, materialised, published, advanced, rebuilt — and released when nobody reads it.

Editable source SVG draw.io All views
Declared counter + board config Materialised first build from buckets Published version served, as-of set Advanced next version, cache warmed Closed or rebuilt sealed, or replayed from log Dematerialised idle scope released Projections versioned validated buckets exist readers pinned on changed keys or corrupt / disputed no reads in 30 d Leaderboard & Counting Service — Projection Lifecycle Application we own Decision point Security / platform The loop closes on dematerialisation, not on deletion: a released scope keeps its buckets and rematerialises on the next read. Rebuild is a step on the normal loop rather than an incident path. v 1.0 · owner Platform Architecture · date 2026-10

Decisions

  • Rebuild is a step on the normal loop, not an incident path. A projection that is rebuilt only in emergencies is a projection whose rebuild does not work.
  • The loop closes on dematerialisation rather than deletion: an idle scope releases its ranked view and keeps its buckets, and rematerialises on the next read.
  • Publication is an explicit transition, which is what lets a bad build be withdrawn by pointing readers back at the previous version.

Numbers (assumptions)

  • Scheduled rebuild of every tenant's largest board at least monthly, at ≥ 10× real-time replay.
  • Dematerialisation after 30 days with no read; rematerialisation on demand within the cache-miss budget.

Risks

  • Rematerialising a cold scope on a read is a latency spike at exactly the moment a dormant product surface gets attention again — typically a marketing campaign.
  • Versioned projections accumulate storage until retirement, and the retirement rule interacts with session-pinned versions.