Skip to content

Feat/redis rate limiter - #17

Closed
raymondproguy wants to merge 8 commits into
mainfrom
feat/redis-rate-limiter
Closed

raymondproguy wants to merge 8 commits into
mainfrom
feat/redis-rate-limiter

Conversation

@raymondproguy

Copy link
Copy Markdown
Contributor

No description provided.

The in-process limiter counts in one process's memory, so N replicas
enforce N times the configured limit. This keeps the same fixed-window
policy and moves the counter into Redis, atomically in one script so
two replicas cannot each arm their own window over the same key.
Injected already constructed, like every store, so the engine never
dials Redis or owns its lifecycle. Nil keeps the in-memory default
built from RateLimitAttempts/RateLimitWindow, which is what every
existing caller gets.
The fake models the Lua rather than running it, so it pins the
allow/deny arithmetic, the fixed window, key namespacing and the
EVALSHA→EVAL fallback — not Redis's own execution of the script.
Runs against an in-process stand-in by default and against a real
server when REDIS_ADDR is set — the second mode is the one that
actually executes the Lua, so both are documented in the header.
Leads on the fail-closed decision, since wiring Redis in makes it a
hard dependency of SignUp/Login/RequestMagicLink and that is the one
thing to settle before deploying rather than during an incident.
Tier 2 is now complete, so NEXT.md opens on Tier 3. PROGRESS.md
records the open gap plainly: no Redis was reachable here, so the Lua
ran only against a modelled stand-in, never a real server.
Added new audit event types for anomaly detection and credential stuffing, along with structures for login attempts and anomaly tracking.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant