type: rule
status: active
timestamp: 2026-06-20
tags: [rules, quotas, architecture, free-tier]
status: active
timestamp: 2026-06-20
tags: [rules, quotas, architecture, free-tier]
Never hit a free-tier quota
Architect for headroom, never hit quotas
Never hit a free-tier quota
Architect every layer with enough headroom that we never approach the free-tier ceiling under realistic load.
Why
The point of staying on free tiers is predictable failure mode: when we hit a quota, the service stops — it does NOT silently bill us. But hitting a quota is still a customer-visible outage. Outages are design failures, not billing events. We should never be surprised.
The layered defense:
- Pick services whose free tier is 10× our forecast load, not 1.1×.
- Cache aggressively at one layer down (build-time JSON, KV, browser localStorage, static HTML) so the upstream quota is never the hot path.
- Push work to build-time GitHub Actions when possible — cron-rebuilt static JSON files have effectively infinite read quota.
- Spread load across data-shape-specific stores so no single quota becomes the bottleneck (see layer-4).
- Monitor approach to quotas, not just hits. If usage crosses 50% of any free-tier ceiling, that’s the trigger to add the next layer.
Exceptions
None. If a feature can only work by riding a quota wall close, the feature is wrong.
See also
no-card-on-file.md— the failure-mode pair- AGENTS.md “five non-negotiable rules” §1