Rate limiting is a feature you regret not having the day a misbehaving client or a scraper hammers your API. The naive approach — a fixed window counter that resets every minute — is easy to abuse: a caller fires a full quota at the end of one window and another at the start of the next, doubling the intended burst.
Two algorithms fix this. A token bucket refills at a steady rate and lets callers spend saved-up tokens for short bursts, matching how real traffic behaves. A sliding window smooths the boundary problem by weighting the previous window for a more accurate rolling count. For most APIs, a token bucket per client key is the pragmatic default.
The hard part on serverless is the lack of shared memory between instances, so an in-process counter limits each instance separately and your real limit becomes a multiple of the intended one. The standard answer is a central store — Redis — with an atomic script so increment and expiry happen as one operation under concurrency.
Key takeaways
- Avoid plain fixed-window counters; they allow double-rate bursts at the window boundary.
- Prefer a token bucket for most APIs because it permits natural short bursts while bounding the average.
- Use a sliding window when you need a smoother, more accurate rolling count near the limit.
- Back the limiter with Redis on serverless so every instance shares one counter instead of its own.
- Return HTTP 429 with a Retry-After header so well-behaved clients back off correctly.
Practical checklist
- Decide the limit key per user, per API key, or per IP, and document the choice.
- Implement the counter as an atomic Redis operation so concurrent requests cannot race.
- Set the right TTL on each key so buckets and windows expire instead of leaking memory.
- Add Retry-After and clear rate-limit headers to your 429 responses.
What to do next week
A correct rate limiter is a small amount of code that quietly protects your database, your bill, and your other users. If you are exposing an API to the public or to partners, we are happy to review your limiting strategy in a short call and make sure it actually holds up across multiple serverless instances rather than per instance.
How we work with clients at TechTrio
Every engagement at TechTrio Automation starts with a short discovery phase: we map your current stack, traffic, conversion paths, and operational bottlenecks. From there we propose a phased roadmap — quick wins first (tracking, analytics hygiene, performance, or a focused automation), then deeper builds (product modules, integrations, or marketing systems). Our teams in Ahmedabad and Mehsana collaborate closely with stakeholders in India, the UK, USA, Canada, and the UAE, so documentation, handoffs, and support hours stay practical.
