Leaderboard & Counting Service · View 08 of 21 · Structure
Decisions
- Admission does four refusals before anything is logged — schema and bounds, idempotency, quota, and the inflation signal — because an event that should not count is cheapest to stop before it is durable.
- The staleness tagger is a component, not a response header added by convention. Every read carries a projection version and an as-of, and that is enforced in one place.
- The poison sink keeps the unparseable event with its parse error. An event the pipeline cannot read is evidence, not noise.
Why the overlay lives in the read path
- Read-your-writes is the one piece of freshness the platform spends, so it is implemented where the cost is bounded: a short lookup of the member's own recent accepted deltas, applied to a stale projection.
- Putting it in the write path instead would mean a synchronous projection update, which is the design this architecture exists to avoid.
Risks
- The Bigtable row-key design is load-bearing for three different access patterns — bucket upsert, window range scan, ranked slice. Getting it wrong is a migration, not a config change.
- Two planes mean two deploy cadences and two on-call surfaces for one product promise.
