--- title: 28 Million Decisions Per Second. Zero Allocations. One... description: RateShield is an open-source Go rate limiting library designed for high-throughput production use. It achieves 28 million decisions per second with zero heap... canonical: https://daily.dev/posts/28-million-decisions-per-second-zero-allocations-one-rate-limiter--a6kmxkmhy twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: 28 Million Decisions Per Second. Zero Allocations. One Rate Limiter. | daily.dev og:description: RateShield is an open-source Go rate limiting library designed for high-throughput production use. It achieves 28 million decisions per second with zero heap... og:url: https://daily.dev/posts/28-million-decisions-per-second-zero-allocations-one-rate-limiter--a6kmxkmhy og:image: https://api.daily.dev/og/posts/a6kMxkmHY.png og:image:alt: 28 Million Decisions Per Second. Zero Allocations. One Rate Limiter. og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 28 Million Decisions Per Second. Zero Allocations. One Rate Limiter. **[Medium](https://daily.dev/sources/medium_js)** · 14 min read · 0 upvotes · 0 comments ## Summary RateShield is an open-source Go rate limiting library designed for high-throughput production use. It achieves 28 million decisions per second with zero heap allocations by using a 64-shard memory store with FNV-1a hashing to minimize lock contention. The library implements four algorithms — Token Bucket, Fixed Window Counter, Sliding Window Counter, and Sliding Window Log — each with different trade-offs. For distributed deployments, it uses atomic Redis Lua scripts to eliminate race conditions across multiple servers. A FallbackStore automatically switches to in-memory limiting when Redis is unavailable and recovers transparently. The post covers the core problems of distributed rate limiting (multi-server counting, race conditions, lock contention, and resilience) and explains the architectural decisions behind each solution, including IP spoofing trade-offs and stress test results. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How can I implement a distributed rate limiter in Go that avoids race conditions across multiple servers? Use a centralized store like Redis with atomic Lua scripts so the read-check-write sequence happens as a single uninterruptible operation, eliminating race conditions where two servers both read a stale count and both allow a request. RateShield, an open-source Go library, implements this pattern with Lua scripts executed inside Redis for fixed window, sliding window, and token bucket algorithms, guaranteeing zero race conditions even under thousands of concurrent workers. _daily.dev surfaces practical patterns like this for developers designing distributed rate limiting in Go._ ### How do I reduce lock contention in a high-concurrency Go in-memory rate limiter? Split the counter storage into multiple independent shards, each guarded by its own lock, instead of using one global sync.Mutex. RateShield uses 64 shards selected via the FNV-1a hash function, so concurrent requests for different keys rarely compete for the same lock, achieving 34.84 nanoseconds per decision with zero heap allocations, roughly 28.7 million decisions per second per CPU core. _engineers tuning Go concurrency performance can track sharding techniques like this via daily.dev._ ### What should a rate limiter do when Redis becomes unavailable? Fall back automatically to a local in-memory counter per server rather than crashing the whole API or silently letting every request through. RateShield's FallbackStore tries the Redis primary first, and on error calls an alert hook and transparently switches to a local memory store; when Redis recovers, the system returns to Redis-backed limiting automatically, and both stores are cleared together on reset to avoid inflated counters. _teams designing resilient failover for Redis-backed services can follow this approach via daily.dev._ ## Similar posts on daily.dev - [Sliding-Window Rate Limiters with TypeScript & Redis](https://daily.dev/posts/sliding-window-rate-limiters-with-typescript-redis-johtnq4x1) · SitePoint · 0 upvotes · 0 comments - [High Performance Rate Limiting at Databricks](https://daily.dev/posts/high-performance-rate-limiting-at-databricks-lln88cxlb) · ByteByteGo · 13 upvotes · 0 comments - [Rate Limiting Algorithms: Token Bucket vs Sliding Window vs Fixed Window](https://daily.dev/posts/rate-limiting-algorithms-token-bucket-vs-sliding-window-vs-fixed-window-c6i3q4jdl) · Arcjet · 0 upvotes · 0 comments - [Python Rate Limiting: The Limiter That Caused Our Outage](https://daily.dev/posts/python-rate-limiting-the-limiter-that-caused-our-outage-2y3xnfeyu) · SitePoint · 0 upvotes · 0 comments --- Tags: [#golang](https://daily.dev/tags/golang), [#distributed-systems](https://daily.dev/tags/distributed-systems), [#redis](https://daily.dev/tags/redis) [View this post on daily.dev](https://daily.dev/posts/28-million-decisions-per-second-zero-allocations-one-rate-limiter--a6kmxkmhy) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"28 Million Decisions Per Second. Zero Allocations. One Rate Limiter.","url":"https://daily.dev/posts/28-million-decisions-per-second-zero-allocations-one-rate-limiter--a6kmxkmhy","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/28-million-decisions-per-second-zero-allocations-one-rate-limiter--a6kmxkmhy"},"datePublished":"2026-07-22T19:36:09.154Z","dateModified":"2026-09-13T19:53:07.625Z","description":"RateShield is an open-source Go rate limiting library designed for high-throughput production use. It achieves 28 million decisions per second with zero heap...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/12c53909dd9f3e8ab1b99ff864101ed7?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/12c53909dd9f3e8ab1b99ff864101ed7?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Medium","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Medium","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/medium","url":"https://daily.dev/sources/medium_js"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/28-million-decisions-per-second-zero-allocations-one-rate-limiter--a6kmxkmhy","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"golang,distributed-systems,redis","timeRequired":"PT14M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Medium","item":"https://daily.dev/sources/medium_js"},{"@type":"ListItem","position":3,"name":"28 Million Decisions Per Second. Zero Allocations. One Rate Limiter."}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/28-million-decisions-per-second-zero-allocations-one-rate-limiter--a6kmxkmhy#faq","mainEntity":[{"@type":"Question","name":"How can I implement a distributed rate limiter in Go that avoids race conditions across multiple servers?","acceptedAnswer":{"@type":"Answer","text":"Use a centralized store like Redis with atomic Lua scripts so the read-check-write sequence happens as a single uninterruptible operation, eliminating race conditions where two servers both read a stale count and both allow a request. RateShield, an open-source Go library, implements this pattern with Lua scripts executed inside Redis for fixed window, sliding window, and token bucket algorithms, guaranteeing zero race conditions even under thousands of concurrent workers. daily.dev surfaces practical patterns like this for developers designing distributed rate limiting in Go."}},{"@type":"Question","name":"How do I reduce lock contention in a high-concurrency Go in-memory rate limiter?","acceptedAnswer":{"@type":"Answer","text":"Split the counter storage into multiple independent shards, each guarded by its own lock, instead of using one global sync.Mutex. RateShield uses 64 shards selected via the FNV-1a hash function, so concurrent requests for different keys rarely compete for the same lock, achieving 34.84 nanoseconds per decision with zero heap allocations, roughly 28.7 million decisions per second per CPU core. engineers tuning Go concurrency performance can track sharding techniques like this via daily.dev."}},{"@type":"Question","name":"What should a rate limiter do when Redis becomes unavailable?","acceptedAnswer":{"@type":"Answer","text":"Fall back automatically to a local in-memory counter per server rather than crashing the whole API or silently letting every request through. RateShield's FallbackStore tries the Redis primary first, and on error calls an alert hook and transparently switches to a local memory store; when Redis recovers, the system returns to Redis-backed limiting automatically, and both stores are cleared together on reset to avoid inflated counters. teams designing resilient failover for Redis-backed services can follow this approach via daily.dev."}}]} ```