Architecture
A rate limiter architecture diagram implementing the token bucket algorithm with Redis-backed distributed counters, sliding window logs, API key identification, rate limit headers, and multi-node synchronization for consistent enforcement. This template shows how to protect APIs from abuse and ensure fair usage across clients, with proper HTTP 429 responses and Retry-After headers. Essential for API platform teams building production-grade rate limiting infrastructure.
Full FlowZap Code
Client { # Client
n1: circle label:"API Request"
n2: rectangle label:"Attach API Key"
n3: rectangle label:"Receive Response"
n4: circle label:"End"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> RateLimiter.n5.handle(top) [label="Request"]
n3.handle(right) -> n4.handle(left)
}
RateLimiter { # Rate Limiter (Token Bucket)
n5: rectangle label:"Extract Client Identity"
n6: rectangle label:"Lookup Rate Limit Config"
n7: rectangle label:"Check Token Bucket"
n8: diamond label:"Tokens Available?"
n9: rectangle label:"Consume Token"
n10: rectangle label:"Return 429 Too Many Requests"
n11: rectangle label:"Add Rate Limit Headers"
n12: rectangle label:"Forward to Backend"
n5.handle(right) -> n6.handle(left) [label="API Key / IP"]
n6.handle(right) -> n7.handle(left) [label="100 req/min"]
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left) [label="Yes"]
n8.handle(bottom) -> n10.handle(top) [label="No"]
n9.handle(right) -> n11.handle(left) [label="Decrement"]
n11.handle(right) -> n12.handle(left) [label="X-RateLimit-Remaining"]
n10.handle(right) -> n11.handle(left) [label="Retry-After"]
n10.handle(top) -> Client.n3.handle(bottom) [label="429"]
n12.handle(bottom) -> Backend.n13.handle(top) [label="Allowed"]
}
Backend { # Backend Service
n13: rectangle label:"Process Request"
n14: rectangle label:"Return Response"
n13.handle(right) -> n14.handle(left) [label="Execute"]
n14.handle(top) -> Client.n3.handle(bottom) [label="200"]
}
Store { # Rate Limit Store (Redis)
n15: rectangle label:"Redis Counter"
n16: rectangle label:"Sliding Window Log"
n17: rectangle label:"Distributed Sync"
n7.handle(bottom) -> Store.n15.handle(top) [label="INCR + EXPIRE"]
n15.handle(right) -> n16.handle(left) [label="Window Check"]
n16.handle(right) -> n17.handle(left) [label="Multi-Node"]
}
Why This Workflow?
Without rate limiting, a single abusive client or a traffic spike can overwhelm your API, degrading performance for all users. A rate limiter enforces fair usage quotas per client, protecting backend services from overload while providing clear feedback through standard HTTP headers.
How It Works
- Step 1: The client identity is extracted from the API key or IP address.
- Step 2: The rate limit configuration is looked up for the identified client tier.
- Step 3: The token bucket in Redis is checked for available tokens.
- Step 4: If tokens are available, one is consumed and the request proceeds with rate limit headers.
- Step 5: If no tokens are available, a 429 Too Many Requests response is returned with a Retry-After header.
- Step 6: Distributed Redis synchronization ensures consistent rate limiting across multiple API gateway nodes.
Alternatives
Application-level rate limiting does not work across multiple instances. Cloud provider rate limiting (AWS API Gateway) is simpler but less customizable. This template shows the distributed token bucket implementation with Redis.
Key Facts
| Template Name | Rate Limiter Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A CQRS read-write separation architecture diagram with dedicated command and query paths, PostgreSQL for writes, Redis or Elasticsearch for optimized reads, and an event-driven synchronization layer with lag monitoring. This template demonstrates the core CQRS principle of separating read and write models to independently scale and optimize each path. Ideal for applications with asymmetric read/write ratios where query performance is critical.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.
Architecture
A microservices decomposition architecture diagram organized by business capabilities: Identity, Product Catalog, Pricing, and Order Fulfillment, each with independent data stores and APIs. This template shows how to break a monolith into services aligned with business domains, using a Backend-for-Frontend (BFF) pattern for client-specific aggregation. Useful for architects planning domain-driven microservice boundaries.
Architecture
A strangler fig migration architecture diagram showing the incremental replacement of a legacy monolith with new microservices, using a routing layer to split traffic between old and new systems. This template models the proven migration strategy where new features are built as microservices while legacy endpoints are gradually retired. Essential for teams modernizing legacy systems without risky big-bang rewrites.