Per-request config-store read on the auction hot path (Cloudflare/Spin KV) — caching?

[aram356]

Summary

Since PR #110 moved bid_cpm from a compile-time constant into the typed config store, the OpenRTB (/openrtb2/auction) and APS (/e/dtb/bid) handlers resolve AppConfig through extract_from_handle → ConfigStore::get on every request. There is no caching layer in the edgezero extractor.

Cost characteristics by adapter:

• Cloudflare Workers — a bare KV read per request (store.get(key).text().await), no cacheTtl, no isolate-level memo. Each auction now costs one billable KV read plus cold-read latency at the PoP.
• Spin — same shape (KV-backed).
• Fastly — config stores are edge-resident; fine.
• Axum — loads the file once at startup; fine.

Raised by @prk-Jr in review of PR #110 — non-blocking, "want the cost characteristics on the record since this PR is what moved pricing onto that path."

The question

Is isolate-lifetime caching of the resolved AppConfig planned in edgezero, or is a cacheTtl on the Cloudflare config-store read worth raising upstream? The extractor is edgezero-owned, so the fix (memo or cacheTtl) most likely belongs there, not in mocktioneer.

Options

• Raise an edgezero issue for an isolate-lifetime AppConfig memo (resolve once per isolate/instance, not per request).
• Or a cacheTtl option on the Cloudflare config-store backend so repeat reads hit the Workers KV cache.
• Mocktioneer-side stopgap (only if upstream won't): a per-instance cache in front of the extractor — but that duplicates framework responsibility and is not preferred.

Notes

• Deterministic-pricing semantics are unaffected either way; this is purely cost/latency.
• Low urgency for a mock bidder, but real for anyone running it at Cloudflare/Spin PoPs under load.