How do you keep rate limits consistent when the API scales to several tasks?

Say it in 30 seconds

Say it like this (20-30 seconds)

I keep the token bucket in shared Redis and refill and consume tokens in one atomic script. MiniTickets uses Redis time so API clock differences do not create extra allowance. Login is limited by client IP and booking by authenticated user. This gives a shared policy across tasks, but it adds a dependency: limiter errors fail closed. I would also review proxy trust and shared-IP fairness before interpreting every rejection as abuse.

The deeper answer

A token bucket permits a burst up to capacity and restores tokens over time. Login has capacity twenty and one token per three seconds; booking has capacity ten and one per second. The script updates the bucket atomically and sets expiry so inactive identities do not accumulate forever.

The limiter hashes identities in key names. That avoids readable raw IPs or user IDs there, but hashing does not automatically make an identifier anonymous or remove privacy obligations. Rejected requests carry a computed retry delay through the API error mapping.

The client IP is only useful if proxy trust matches the deployment path. Trusting too few hops can group everyone under a load-balancer IP. Trusting too many can allow caller-supplied forwarding data to influence the result. Even a correct IP can represent an office network with many legitimate users. Production policies need layered identity and evidence rather than simply increasing every limit.

Counter-questions

What if Redis is slow or unavailable?

The limiter reports a temporary service-unavailable error rather than allowing unbounded password hashing or writes. A request carrying sid may already fail in session lookup before the limiter executes.

Why not keep a Map in each API task?

Each task would allow its own full bucket, so adding tasks would multiply the effective allowance and restarts would reset it. Shared atomic state keeps the policy consistent.

Would you use the same identity for every operation?

No. Anonymous login needs an abuse signal such as IP, while authenticated booking can use user identity. Shared networks, malicious accounts and distributed attacks require different policies.

Where in MiniTickets

Read Rate limits inventory gate, then inspect the rate-limiter piece →.

apps/api/src/queries/rate-limits.ts → takeToken

See the real users get 429 case.