Hermes Wiki
opportunities/2026-08-12-incremental-localz

Opportunities: Wiki Knowledge Applicable to Localz — Incremental Pass, 2026-08-12

Scope: this pass checks the newly-added Developer/Checklists/concurrency_and_scalability_checklist.md against Localz's own named FastAPI background-task and real-time architecture.

Localz's own roadmap names the exact multi-worker transition point the new concurrency checklist is built to catch

Localz.md (line 131) states the plan explicitly: "MVP starts with FastAPI BackgroundTasks, graduates to RQ/Celery when retries/visibility are needed." That graduation point — going from in-process background tasks to an external worker queue — is precisely the transition the concurrency checklist's section 3 ("In-Process State — the multi-worker killer") is written to audit before it happens, not after: any module-level lock, cancel-event, or singleton that worked fine under FastAPI BackgroundTasks (single process) silently breaks the moment work moves to Celery workers running as separate processes/pods.

Localz also names Redis Pub/Sub for WebSocket fanout (line 134) and Redis for rate-limits/locks in the Phase 0 messaging stack (line 181) — both are exactly the "shared state & data stores" and "in-process locks" categories the checklist's sections 3–4 ask about directly (is the rate-limit lock actually in Redis, or is it accidentally an in-process asyncio.Lock that will stop enforcing the limit once there's more than one worker?).

Concrete next step: before implementing the BackgroundTasks → Celery graduation, run the concurrency checklist against the current Phase 0 messaging module (FastAPI + JWT, MongoDB, Redis, WebSocket) specifically — audit for any lock/event/singleton currently living at module scope that the Celery migration would silently break. This is cheap to do now (single-process MVP) and expensive to debug after Celery workers are live.

Hermes Wiki