Follow-up from the #77 security review (non-blocking there).
The /auth/* rate limiter added for #32 is per-process and in-memory: on a multi-instance deployment the effective limit becomes limit × instances, and instance restarts reset all windows. That's fine for the single-instance launch planned in #28, but scaling out needs one of:
- a shared counter store (Redis, or a Postgres upsert given we already run Postgres), or
- Fly's edge rate-limiting in front of the app.
Also relevant then: fixed windows admit a 2× burst across the boundary; a sliding window via the shared store would fix both at once.
Not urgent until #28 runs more than one instance.
Follow-up from the #77 security review (non-blocking there).
The /auth/* rate limiter added for #32 is per-process and in-memory: on a multi-instance deployment the effective limit becomes limit × instances, and instance restarts reset all windows. That's fine for the single-instance launch planned in #28, but scaling out needs one of:
Also relevant then: fixed windows admit a 2× burst across the boundary; a sliding window via the shared store would fix both at once.
Not urgent until #28 runs more than one instance.