6a:T452,### FR-2: Client Identification Rate limiting requires identifying 'who' is making requests. The choice of identity is critical: **By API Key:** - Most common for authenticated APIs - Clear ownership and accountability - Easy to track, quota, and bill - Challenge: Key sharing and leakage **By User ID:** - Limits per authenticated user regardless of which API key - Prevents users from creating multiple keys to bypass limits - Requires authentication before rate limiting **By IP Address:** - Works for unauthenticated endpoints - Problematic: NAT/proxies make many users share IPs - Corporate networks often show as single IP - Mobile carriers do the same **By Composite Key:** - Combine multiple factors (e.g., API key + endpoint) - Allows different limits for different operations - Example: 10,000/hour for reads, 100/hour for writes **Identity Hierarchy:** Production systems often apply multiple limits: 1. Global rate limit (protect infrastructure) 2. Organization rate limit (aggregate for billing) 3. User rate limit (individual fair use) 4. Endpoint-specific limits (expensive operations)6b:T450,### FR-3: Multiple Limit Dimensions Real-world APIs need limits at multiple time scales and dimensions: **Time Dimensions:** ``` Per-second: 50 requests/second (prevent bursting) Per-minute: 1,000 requests/minute (sustained rate) Per-hour: 20,000 requests/hour (capacity planning) Per-day: 100,000 requests/day (quota management) ``` **Resource Dimensions:** ``` /api/search: 60 requests/minute (expensive computation) /api/data: 1,000 requests/minute (cached reads) /api/upload: 10 requests/minute (storage-intensive) /api/webhook: 100 requests/hour (third-party integration) ``` **Combining Limits:** A single request might be evaluated against multiple limits: 1. Global: Under 10M requests/hour total? ✓ 2. Organization: Under 100K requests/hour for this org? ✓ 3. User: Under 1K requests/hour for this user? ✓ 4. Endpoint: Under 60 requests/minute for /search? ✗ REJECT **Limit Inheritance:** Some systems support hierarchical limits where child entities inherit parent limits. An organization limit of 100K/hour applies to all users, with individual users getting 10K/hour within that.6c:T687,// Core rate limiting interface interface RateLimiter { // Check if request is allowed and consume quota // Returns decision with metadata for headers checkLimit(request: RateLimitRequest): Promise; // Preview limit status without consuming quota getStatus(clientId: string, ruleId: string): Promise; // Administrative operations resetLimit(clientId: string, ruleId?: string): Promise; overrideLimit(clientId: string, override: LimitOverride): Promise; } interface RateLimitRequest { clientId: string; // API key, user ID, or IP resource: string; // Endpoint or resource being accessed cost?: number; // Request weight (default 1) timestamp?: number; // Request time (default now) } interface RateLimitDecision { allowed: boolean; // Is request permitted? remaining: number; // Requests remaining in window limit: number; // Total limit for this window resetAt: number; // When window resets (Unix ms) retryAfter?: number; // Seconds to wait if denied rule: string; // Which rule triggered limit } interface LimitStatus { current: number; // Current count in window limit: number; // Maximum allowed remaining: number; // Requests remaining resetAt: number; // Window reset time windowSize: number; // Window duration in seconds } interface LimitOverride { limit?: number; // Override limit value expiresAt?: number; // When override expires reason: string; // Audit trail }62:{"json":{"id":"seed_a3137c596b90f007be85e26f8bc5d195","slug":"rate-limiter","category":"System Design (HLD)","topic":"Rate Limiter","title":"Designing a Rate Limiter","description":"Master the art of building production-grade rate limiters that protect APIs from abuse, ensure fair usage, and maintain system stability. Learn token bucket, sliding window algorithms, distributed rate limiting strategies, and how to communicate limits effectively to clients.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_9864e04c2eec1a029ede437d8098a1a5","title":"Requirements: Limit API Requests","order":0,"content":[{"id":"opening-hook","title":"The Invisible Guardian of Every API","content":[{"data":{"content":"Every successful API in production has an invisible guardian standing between clients and servers—a **Rate Limiter**. This critical component silently defends against abuse, ensures fair resource distribution, and maintains system stability even when millions of requests surge simultaneously.\n\nWithout rate limiting, a single misbehaving client could monopolize server resources, denial-of-service attacks would be trivially easy, and runaway scripts could generate bills that bankrupt companies. Rate limiting isn't optional for production systems—it's existential.\n\nIn this module, we'll design a production-grade rate limiter from first principles, covering the algorithms, architecture, and operational considerations that separate toy implementations from systems protecting real-world APIs at companies like Stripe, GitHub, and Cloudflare."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you'll understand: (1) Why rate limiting is essential for any production API, (2) The complete functional requirements for a rate limiter, (3) Non-functional requirements including latency, throughput, and fault tolerance, (4) Back-of-envelope estimations for scale, and (5) The key design decisions that shape rate limiter architecture.","variant":"info"},"type":"callout"}]},{"id":"why-rate-limiting","title":"Why Rate Limiting Matters","content":[{"data":{"content":"Rate limiting controls how frequently clients can make requests to an API within a given time window. This seemingly simple concept addresses multiple critical concerns that every production system must handle. Let's understand the fundamental motivations driving rate limiter design."},"type":"text"},{"data":{"items":["**Prevent Resource Starvation** — Without rate limits, a single client could consume all available server resources, starving legitimate users. A single runaway script making 10,000 requests/second could bring down an entire service.","**Defense Against Denial of Service** — Rate limiting is the first line of defense against DoS attacks. By limiting request rates, attackers cannot overwhelm servers with volume alone.","**Cost Control** — Cloud resources cost money. An abusive client generating 100x normal traffic translates directly to 100x infrastructure costs. Rate limiting protects business sustainability.","**Fair Resource Distribution** — When capacity is constrained, rate limiting ensures all clients get reasonable access rather than first-come-first-served chaos.","**Enforce Business Tiers** — APIs often have different pricing tiers (free, pro, enterprise). Rate limiting enforces these contractual boundaries programmatically.","**Protect Downstream Dependencies** — Your API likely depends on databases, caches, and third-party services. Rate limiting prevents cascading failures when clients overwhelm your system."],"title":{"icon":"Target","text":"Core Motivations for Rate Limiting","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"Real-World Incident: The $72,000 API Call","content":"In 2019, a startup's developer accidentally deployed a script with an infinite loop calling their cloud provider's API. Without rate limiting on their own internal services, the script ran for 6 hours before detection, generating a $72,000 bill from API and compute charges. Proper rate limiting would have stopped this within seconds.","variant":"warning"},"type":"callout"},{"data":{"content":"**The economics of rate limiting:**\n\nConsider a simple example: An API server can handle 10,000 requests per second (rps) sustainably. During normal operation, you have 1,000 clients each making 5 rps = 5,000 rps total (50% utilization, healthy headroom).\n\nNow imagine one client's code has a bug causing 100 rps instead of 5:\n- Without rate limiting: That client consumes 1% of capacity, reducing headroom\n- With 10 buggy clients: 1,000 rps consumed, other clients start experiencing latency\n- With 100 buggy clients: 10,000 rps consumed, system is overwhelmed, all clients fail\n\nRate limiting at 10 rps per client means those 100 buggy clients together only consume 1,000 rps—the system remains healthy while you notify affected clients to fix their code."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"functional-requirements","title":"Functional Requirements","content":[{"data":{"content":"Before designing any system, we must precisely define what it needs to do. For a rate limiter, the functional requirements establish the core behaviors and capabilities that the system must provide. We'll analyze each requirement in depth, considering variations and edge cases."},"type":"text"},{"data":{"rows":[["Limit Request Rate","Restrict number of requests per time window per identity","Max 1000 requests per hour per API key"],["Identify Clients","Determine who is making requests for rate limit tracking","By API key, user ID, IP address, or combination"],["Reject/Allow Decision","Make a binary decision for each request","Return 200 OK or 429 Too Many Requests"],["Communicate Limits","Inform clients of their current state and limits","X-RateLimit-Remaining: 423 headers"],["Support Multiple Limits","Apply different limits at different granularities","100/min AND 5000/hour per user"],["Reset Windows","Clear counters when time windows expire","Counter resets at top of each minute"]],"caption":"Core Functional Requirements","headers":["Requirement","Description","Example"]},"type":"table"},{"data":{"content":"### FR-1: Accurate Rate Limiting\n\nThe rate limiter must accurately count requests and enforce configured limits. This sounds trivial but involves subtle complexity:\n\n**Time Window Definition:**\n- Fixed windows (e.g., 1:00-1:01, 1:01-1:02) are simple but create boundary problems\n- Sliding windows provide smoother limiting but require more computation\n- Token buckets allow bursting while maintaining long-term averages\n\n**Counting Accuracy:**\n- In distributed systems, counts may be slightly inconsistent across nodes\n- The system should either be slightly conservative (allow fewer than limit) or slightly lenient (allow more)\n- Perfect accuracy is impossible; we define acceptable error bounds\n\n**Request Attribution:**\n- What constitutes 'one request'? All HTTP calls? Only POSTs? Only successful calls?\n- Should retries count? Should OPTIONS preflight requests count?\n- These decisions significantly impact client experience."},"type":"text"},{"data":{"icon":"Info","title":"Design Decision: Counting Policy","content":"Most production rate limiters count all requests regardless of outcome. Counting only successful requests would allow attackers to make unlimited malformed requests. Counting only specific methods (like POST) would leave other methods unprotected. The safest default is counting everything, with the option to exclude health checks and monitoring endpoints.","variant":"note"},"type":"callout"},{"data":{"content":"$6a"},"type":"text"},{"data":{"content":"$6b"},"type":"text"},{"data":{"items":["**Burst Allowance** — Allow clients to temporarily exceed rates if they've been below quota. Token bucket algorithms excel at this.","**Graceful Degradation** — When limits are hit, prefer slowing down to hard rejections when possible (response delays).","**Exempt Traffic** — Some traffic (health checks, internal monitoring) should bypass rate limits.","**Override Capability** — Operators need emergency ability to raise/lower limits without deployment.","**Audit Trail** — Which requests were rate limited? When? This data is essential for debugging and customer support."],"title":{"icon":"Lightbulb","text":"Additional Functional Considerations","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"titleType":"number","titleNumber":2},{"id":"non-functional-requirements","title":"Non-Functional Requirements","content":[{"data":{"content":"Non-functional requirements (NFRs) define how well the system performs its functions. For a rate limiter, NFRs are exceptionally important because the rate limiter sits in the critical path of every API request. Any deficiency in the rate limiter directly impacts the entire system."},"type":"text"},{"data":{"left":[{"data":{"items":["**Latency** — Sub-millisecond p99. The rate limiter adds overhead to every request; this must be negligible.","**Throughput** — Handle millions of decisions per second across all rate limiter instances.","**Memory Efficiency** — Track millions of unique clients without excessive memory consumption.","**CPU Efficiency** — Decision computation must be O(1) per request, not proportional to history."],"title":{"icon":"Zap","text":"Performance Requirements","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Availability** — 99.99%+. Rate limiter downtime means either all traffic blocked or unlimited.","**Consistency** — Limits should be enforced consistently across distributed nodes.","**Fault Tolerance** — Continue operating during network partitions and node failures.","**No Single Point of Failure** — Distributed architecture with graceful degradation."],"title":{"icon":"Target","text":"Reliability Requirements","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"### NFR-1: Ultra-Low Latency\n\nThe rate limiter is in the hot path of every API request. Consider the impact of latency:"},"type":"text"},{"data":{"rows":[["1ms","1M","1,000 seconds added delay"],["0.1ms","1M","100 seconds added delay"],["0.01ms","1M","10 seconds added delay"]],"headers":["Rate Limiter Latency","Requests/sec","Daily Latency Impact"]},"type":"table"},{"data":{"content":"**Target: p50 < 0.1ms, p99 < 1ms, p99.9 < 5ms**\n\nTo achieve this:\n- Use in-memory data structures when possible\n- Minimize network round trips (local caching)\n- Avoid locks in the hot path\n- Pre-compute rate limit configurations"},"type":"text"},{"data":{"content":"### NFR-2: Massive Scale Throughput\n\nAt enterprise scale, rate limiters must handle enormous throughput:\n\n**Scale Targets:**\n- Decisions per second: 1-10 million\n- Unique identities tracked: 10-100 million\n- Rules evaluated per decision: 3-10\n- Geographic distribution: 5-20 regions\n\n**Scaling Approach:**\n- Horizontal scaling: Add more rate limiter nodes\n- Sharding: Different clients handled by different nodes\n- Local caching: Reduce distributed coordination\n- Batching: Aggregate updates before synchronization"},"type":"text"},{"data":{"content":"### NFR-3: Fault Tolerance and Graceful Degradation\n\nWhat happens when the rate limiter itself has problems? This is a critical design decision:\n\n**Option A: Fail Open (Allow all traffic)**\n- Pro: Service remains available during rate limiter failures\n- Con: No protection during outages; potential for abuse and overload\n- Best for: Internal services, low-risk APIs\n\n**Option B: Fail Closed (Reject all traffic)**\n- Pro: Maximum protection during failures\n- Con: Complete service outage if rate limiter fails\n- Best for: High-security, payment, or critical APIs\n\n**Option C: Fail with Cached State (Allow based on last known state)**\n- Pro: Reasonable protection with continued service\n- Con: Stale data may allow some abuse or wrongly block legitimate clients\n- Best for: Most production APIs\n\n**Option D: Local Fallback**\n- Each application node has local rate limiting as backup\n- Continues protecting during distributed rate limiter failures\n- Less accurate but maintains protection"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Industry Standard: Fail Open with Local Limits","content":"Most production systems use fail-open for distributed rate limiting but maintain local (per-node) rate limits as a fallback. This ensures that even during central rate limiter failures, no single client can overwhelm any individual application node. Services remain available while still protected.","variant":"tip"},"type":"callout"},{"data":{"rows":[["p50 Latency","< 0.1ms","Imperceptible overhead on requests"],["p99 Latency","< 1ms","Tail latency still negligible"],["Availability","99.99%","Better availability than APIs it protects"],["Throughput","1M+ decisions/sec/node","Handle peak traffic with headroom"],["Memory per client","< 100 bytes","Support 100M clients with 10GB RAM"],["Recovery time","< 10 seconds","Fast recovery from node failures"],["Data staleness","< 1 second","Near-real-time accuracy"]],"caption":"Non-Functional Requirements Summary","headers":["Requirement","Target","Rationale"]},"type":"table"}],"titleType":"number","titleNumber":3},{"id":"estimation","title":"Back-of-Envelope Estimation","content":[{"data":{"content":"Before designing the system, let's estimate the scale we need to support. We'll consider a rate limiter for a large API platform serving global traffic—similar to Stripe, Twilio, or GitHub's API infrastructure."},"type":"text"},{"data":{"icon":"Info","title":"Estimation Scenario","content":"We're designing a rate limiter for a large API platform with: 10 million active API keys, 100 million API calls per hour at peak, serving requests globally across 10 geographic regions, with a 99.99% availability requirement.","variant":"note"},"type":"callout"},{"data":{"content":"### Traffic Estimation\n\n**Request Volume:**\n```\nPeak requests per hour: 100,000,000\nPeak requests per second: 100M / 3600 = ~28,000 rps\nWith 3x headroom for spikes: 84,000 rps target capacity\nPer region (10 regions): 8,400 rps per region\n```\n\n**Rate Limit Decisions:**\nEach request requires rate limit evaluation:\n```\nDecisions per second: 28,000 (1 per request)\nWith multiple rules per decision (avg 5): 140,000 rule evaluations/sec\nPer region: 14,000 rule evaluations/sec\n```\n\n**Update Frequency:**\nEach decision updates counters:\n```\nCounter updates per second: 28,000\nWith distributed sync (100ms batching): 280 sync operations/sec\n```"},"type":"text"},{"data":{"content":"### Storage Estimation\n\n**Per-Client Storage (Token Bucket):**\n```\nClient ID (hash): 8 bytes\nLast refill time: 8 bytes\nToken count: 8 bytes\nBucket size/rate: 8 bytes\nTotal per client: ~32 bytes\nWith overhead: ~50 bytes per bucket\n```\n\n**Multiple Buckets per Client:**\n```\nAverage buckets per API key: 3 (by time window)\nEndpoint-specific buckets: 5 common endpoints\nTotal buckets per API key: ~8 buckets\nStorage per API key: 8 × 50 = 400 bytes\n```\n\n**Total Active Storage:**\n```\nActive API keys: 10,000,000\nStorage per key: 400 bytes\nTotal: 10M × 400 = 4 GB\nWith 2x headroom: 8 GB\n```\n\n**Per Region:**\n```\nTotal keys (replicated): 10,000,000\nStorage: 8 GB per region\n10 regions: 80 GB total across infrastructure\n```"},"type":"text"},{"data":{"content":"### Network Estimation\n\n**Synchronization Traffic:**\n```\nCounter updates per second: 28,000\nUpdate message size: ~50 bytes (key + delta)\nInter-region sync frequency: 100ms batches\nUpdates per batch: 2,800\nBatch size: 2,800 × 50 = 140 KB per region\nSync with 9 other regions: 1.26 MB per batch\nSync bandwidth: 1.26 MB × 10/sec = 12.6 MB/sec\n```\n\n**Client Communication:**\n```\nRate limit headers: ~100 bytes per response\nAt 28,000 rps: 2.8 MB/sec additional header overhead\n```\n\nThis is well within network capacity for modern infrastructure."},"type":"text"},{"data":{"rows":[["Peak RPS","28,000 (84K with headroom)","Globally distributed"],["Rule evaluations/sec","140,000","Average 5 rules per request"],["Active clients","10 million","API keys with recent activity"],["Storage per region","8 GB","In-memory for speed"],["Cross-region sync","12.6 MB/sec","Batched every 100ms"],["Decision latency budget","< 1ms p99","Critical path"],["Nodes per region","3-5","For redundancy and load"]],"caption":"Estimation Summary","headers":["Metric","Estimate","Notes"]},"type":"table"}],"titleType":"number","titleNumber":4},{"id":"design-decisions","title":"Key Design Decisions","content":[{"data":{"content":"Based on our requirements and estimations, several key design decisions will shape our rate limiter architecture. Let's examine the major trade-offs."},"type":"text"},{"data":{"items":["**Algorithm Choice** — Token bucket vs. sliding window vs. fixed window. Each offers different trade-offs between accuracy, memory, and burst handling. We'll explore token bucket and sliding window in detail in subsequent pages.","**Centralized vs. Distributed** — A single rate limiter is simpler but creates a bottleneck and single point of failure. Distributed rate limiting adds complexity but scales horizontally.","**Synchronous vs. Asynchronous** — Check limits synchronously (blocking) for accuracy, or asynchronously (non-blocking) for speed with eventual consistency.","**In-Memory vs. Persistent Storage** — Memory is fast but volatile. Persistence survives restarts but adds latency. Hybrid approaches use memory with async persistence.","**Strict vs. Approximate Limiting** — Exact counting is expensive at scale. Approximate algorithms (like HyperLogLog) trade accuracy for efficiency."],"title":{"icon":"Target","text":"Critical Design Decisions","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"left":[{"data":{"items":["Token bucket for per-client limits (smooth, allows burste)","Sliding window for high-accuracy limits (premium tiers)","Distributed with local caching (balance speed and accuracy)","In-memory with async persistence (fast recovery)","Fail-open with local fallback (available but protected)"],"title":{"icon":"CheckCircle","text":"Recommended Approach","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Fixed windows alone (boundary spikes)","Fully synchronous distributed checks (latency)","Pure in-memory without persistence (data loss)","Single centralized instance (bottleneck)","Complex multi-phase algorithms (maintenance burden)"],"title":{"icon":"XCircle","text":"Approaches to Avoid","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"### High-Level Architecture Preview\n\nBased on these decisions, our rate limiter architecture will consist of:\n\n1. **Local Rate Limiter (per application node)**\n - In-memory token buckets\n - Sub-millisecond decisions\n - First line of defense\n\n2. **Distributed Counter Service**\n - Aggregates counts across nodes\n - Eventually consistent synchronization\n - Shared state for accurate limiting\n\n3. **Configuration Service**\n - Stores rate limit rules\n - Dynamic updates without deployment\n - Rule versioning and rollback\n\n4. **Analytics Pipeline**\n - Tracks rate limit events\n - Dashboards and alerting\n - Client usage patterns\n\nIn the following pages, we'll dive deep into the algorithms (token bucket, sliding window), distributed rate limiting strategies, and client communication patterns."},"type":"text"}],"titleType":"number","titleNumber":5},{"id":"api-interface","title":"API Interface Design","content":[{"data":{"content":"Before implementation, let's define the interfaces our rate limiter will expose. These APIs serve both internal rate-checking and external configuration management."},"type":"text"},{"data":{"code":"$6c","fileName":"rate-limiter-interface.ts","showLineNumbers":true},"type":"code"},{"data":{"content":"### HTTP Response Headers\n\nFollowing industry standards (RFC 6585, RFC 7231), our rate limiter communicates limits via HTTP headers:\n\n**Standard Headers:**\n```\nX-RateLimit-Limit: 1000 # Maximum requests in window\nX-RateLimit-Remaining: 423 # Requests remaining\nX-RateLimit-Reset: 1609459200 # Unix timestamp of window reset\nRetry-After: 37 # Seconds to wait (on 429)\n```\n\n**Extended Headers (Optional):**\n```\nX-RateLimit-Policy: 1000;w=3600;burst=50 # Policy details\nX-RateLimit-Scope: user # What identity is limited\nX-RateLimit-Resource: /api/search # Which endpoint\n```\n\nThese headers enable clients to:\n1. Implement client-side throttling\n2. Display usage to users\n3. Gracefully handle approaching limits\n4. Retry at appropriate times"},"type":"text"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: Rate Limiter Requirements","content":[{"data":{"content":"We've established a comprehensive understanding of what a production-grade rate limiter requires. Let's consolidate the key takeaways:"},"type":"text"},{"data":{"type":"ordered","items":["**Rate limiting is essential** — It protects against resource starvation, DoS attacks, runaway costs, and unfair usage. Every production API needs it.","**Multiple dimensions** — Effective rate limiting applies limits by identity, time window, and resource. Hierarchical limits prevent gaming.","**Extreme performance** — Sub-millisecond latency is non-negotiable. The rate limiter is in every request's critical path.","**Fault tolerance is paramount** — The rate limiter must be more reliable than the APIs it protects. Fail-open with local fallback is recommended.","**Client communication matters** — Clear headers and error messages enable clients to handle limits gracefully.","**Scale considerations drive design** — At 10M+ clients and 100M+ requests/hour, every byte of storage and every microsecond matters."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nIn the following pages, we'll dive into the core algorithms that power rate limiting:\n- **Page 2: Token Bucket Algorithm** — The classic approach enabling smooth rate limiting with burst support\n- **Page 3: Sliding Window Algorithm** — Precise rate limiting without boundary problems\n- **Page 4: Distributed Rate Limiting** — Coordinating limits across multiple nodes and regions\n- **Page 5: Per-User vs Per-API Limits** — Designing flexible, hierarchical rate limiting policies\n- **Page 6: Client Communication** — Headers, error responses, and retry guidance"},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the comprehensive requirements for building a production-grade rate limiter. You can articulate why rate limiting is essential, define functional and non-functional requirements, estimate scale, and identify key design decisions. Next, we'll implement the core algorithms.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_2b06ddcac3eb756a077670e353223a29","title":"Token Bucket Algorithm","order":1,"content":null,"isLocked":true},{"id":"seed_dd0937352f58ecd629d66b1a9d1d15f6","title":"Sliding Window Algorithm","order":2,"content":null,"isLocked":true},{"id":"seed_3326947a9d36821d8edf9fe902c50602","title":"Distributed Rate Limiting","order":3,"content":null,"isLocked":true},{"id":"seed_3663bc6765ebc004bb3230ab8aa40696","title":"Per-User vs Per-API Limits","order":4,"content":null,"isLocked":true},{"id":"seed_c97292c2e4fbb9c64ba995f80f75f527","title":"Client Communication","order":5,"content":null,"isLocked":true}]}}