usage-summary is a linear scan over the customer's events (~2.7 µs/event): ~330 ms at 110k events, ~520 ms at 195k — needs a rollup

[sagarsuperuser]

What the benchmark found

The read probe running alongside ingest (5 req/s: GET /v1/usage-summary/{customer} over 30 days, GET /v1/invoices, GET /v1/customers) measured, per endpoint, from raw k6 samples on the AWS rig (2026-08-16):

rows in usage_events	≈ events per customer (200 customers)	usage-summary p50	p99	invoices / customers p99
22M	110k	332 ms	342 ms	3–4 ms
25M	125k	354 ms	362 ms	3 ms
39M	195k	523 ms	554 ms	8–9 ms

Independent of write rate (same numbers at 200, 1,000 and 10,000 ev/s); linear in events-per-customer at ~2.7 µs/event. usage.Service.GetSummary → store.Aggregate is a COUNT(*) + SUM GROUP BY meter_id over the customer's rows in the window with no rollup, so a customer with >~180k events/month misses a 500 ms p99 budget under any load.

Suggested fix

The classic one: a per-customer, per-meter daily rollup (materialised on ingest or by a periodic job) that the 30-day summary reads, with only the current partial day aggregated live. Also matches the "no rollups" ceiling already noted in the scale notes.

Documented in docs/benchmarks/sustained-throughput.md (§ "What the read probe found").