Localz — Rate Limiting Algorithm Choice (Incremental)
The previous incremental pass matched a new caching-layer note to Localz's mandatory Redis dependency. One more Architecture/Fundamentals/ note landed today (architecture: 4 new notes, 17:12 UTC) that closes a gap in the same Redis-backed area: rate-limiting-algorithms.
Rate Limiting Algorithms — Localz already committed to Redis-backed rate limiting without picking an algorithm
Projects/Localz.md §5 names Redis as mandatory even at MVP explicitly for "sessions + CSRF + OTP throttles, rate limiting" (the confirmed stack table), and §6's Minimal-to-Production-Security-Implementation.md summary gives a concrete, already-decided number that has no algorithm behind it yet: "rate limit ~20 msg/min per user" for Phase 0 in-app messaging, plus "secure contact forms" needing "rate limiting + CAPTCHA" per Secure-Communication-Design.md. Rate Limiting Algorithms is a direct, actionable match:
- OTP throttles (§5, cash-payment start/end verification) are exactly the abuse-sensitive case the note calls out — it explicitly warns "avoid fixed window counter for anything abuse-sensitive — the 2x boundary burst is a known, easily-triggered gap" and instead recommends token bucket or sliding window counter for this shape of problem.
- The 20 msg/min chat limit is a burst-tolerant, client-fairness case — the note's default recommendation ("use token bucket as the default for public/partner-facing APIs... matches how real clients behave: idle, then a burst of calls") applies directly and is a better fit than the fixed-window counter Phase 0's "Redis rate limits/locks" language leaves ambiguous.
- The note's closing line — "in a distributed system, all of these need a shared, low-latency store (Redis is the default)" — is not new information for Localz (Redis is already locked in), but it confirms the mandatory-Redis decision was correct for this specific use case, not just caching/sessions.
This also connects to the 2026-07-26 caching-layer match — both notes now cover the two concrete Redis-backed cross-cutting concerns (cache invalidation and rate limiting) that Localz's stack docs name but don't design in detail.
Suggested next step
When Phase 0 messaging is scaffolded ("This week (10 hrs) action list" in Projects/Localz.md §6 — "add Redis rate limits + basic moderation + audit log"), pick token bucket for the 20 msg/min chat limit and OTP-generation throttle specifically (not a hand-rolled fixed-window counter) — this is cheap to get right at implementation time and expensive to retrofit once clients depend on the burst behavior of whatever ships first.