# rate-limiting Published articles for rate-limiting. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How API Design Is Evolving for AI Agents, Security, Reliability, and Compliance DevFeed: [How API Design Is Evolving for AI Agents, Security, Reliability, and Compliance]() Original publisher: [Read original article]() Author: J Simpson Published: 2026-09-17T07:00:00Z Content type: article Language: en Sources: [Nordic APIs]() Topics: [API](), [Architecture & Design](), [Artificial Intelligence](), [reliability](), [Security]() Tags: [agents](), [ai-agents](), [api](), [api-architecture](), [api-as-a-product](), [api-design](), [api-discovery](), [api-security](), [architecture](), [authorization](), [blog](), [mcp](), [microservices](), [rate-limiting](), [reliability](), [security]() ### AI overview This article examines six ways API design is evolving as APIs serve AI agents and other machine consumers, with implications for security, reliability, and regulatory compliance. ### Source excerpt For over two decades, API design and architecture remained remarkably consistent. Perhaps it's the outsized influence of Roy Fielding's RESTful dissertation, but API designers have stuck to the principles of stateless architecture, resource-based endpoints, and HTTP commands to an impressive degree. That's all starting to change, now that we've radically recontextualized the way we use ... ## Patching This Site's MCP Endpoint and Limiting What It Can Do DevFeed: [Patching This Site's MCP Endpoint and Limiting What It Can Do]() Original publisher: [Read original article]() Author: Brent Leekley Published: 2026-09-08T00:00:00Z Content type: tutorial Language: en Sources: [brent.leekley.me blog]() Topics: [Model Context Protocol](), [MCP Server](), [API](), [HTTP](), [JSON]() Tags: [aeo](), [agent-ready-website](), [agentic-ai](), [agents](), [api](), [api-security](), [clients](), [json-rpc](), [logs](), [mcp](), [mcp-server](), [model-context-protocol](), [prompt-injection](), [protocol](), [rate-limiting](), [retry](), [server](), [streamable-http](), [webmcp]() ### AI overview This article explains how to patch a website's public, unauthenticated MCP endpoint. It covers updating to the current protocol revision while retaining compatibility with older clients, and applying limits including read-only tools, per-IP rate limiting, request-size caps, Origin checks, POST-only access, non-reflected strings, and privacy-preserving logs. ### Source excerpt An MCP server on your website is a public, unauthenticated API. Bringing one to the current protocol revision while keeping older clients working, and the seven limits that bound it: read-only tools, a per-IP rate limit that always sends Retry-After, hard caps on body and argument size, an https-only Origin check, POST only, no reflected strings, and logs that store a salted hash instead of an address. ## How to Deal With Errors and Failures in LLM-Powered Applications DevFeed: [How to Deal With Errors and Failures in LLM-Powered Applications]() Original publisher: [Read original article]() Author: ByteByteGo Published: 2026-09-07T15:31:35Z Content type: tutorial Language: en Sources: [ByteByteGo]() Topics: [Large Language Model](), [App](), [Language models]() Tags: [applications](), [concurrency-control](), [errors](), [how-to](), [llm](), [rate-limiting](), [resiliency](), [retry]() ### AI overview A tutorial on error handling and resiliency for LLM-powered applications. It covers failures such as unavailable networks, rejected requests, invalid JSON, hallucinations, slow responses, timeouts, retries, fallbacks, circuit breakers, rate limiting, queues, concurrency control, safe tool calls, and response streaming. ### Source excerpt Apart from normal processing, the application also sends data to a large language model (LLM). It then uses the model's response to carry out a task. ## Rootless Podman: Preserving Source IPs DevFeed: [Rootless Podman: Preserving Source IPs]() Original publisher: [Read original article]() Author: Jan Rodak Published: 2026-09-04T14:25:02Z Content type: article Language: en Sources: [blog.podman.io]() Topics: [podman](), [Containers](), [Networks](), [Access Control](), [Logging]() Tags: [blog](), [bridge](), [container](), [containers](), [ipv4](), [ipv6](), [logging](), [networks](), [podman](), [port](), [rate-limiting](), [routing](), [tips-and-tricks]() ### AI overview This article explains how Pesto, a companion tool from the passt project, addresses Rootless Podman's inability to preserve incoming client source IPs on bridge networks. Pesto updates pasta's forwarding table so traffic reaches containers without source-address rewriting, while retaining existing port-mapping capabilities. The article also documents configuration steps, traffic flow, supported networking features, and limitations when switching from the current forwarder. ### Source excerpt Rootless Podman has a long-standing limitation reported since 2020: containers on bridge networks can't see the real source IP of incoming connections. The `rootlessport` userspace proxy rewrites the source to the container's own subnet address, breaking IP-based access control, logging, and rate limiting. Pesto, a new companion tool from the passt project solves this. Pesto [...] ## Fixed window, sliding window, or token bucket? Choosing a rate limit strategy in Appwrite Firewall DevFeed: [Fixed window, sliding window, or token bucket? Choosing a rate limit strategy in Appwrite Firewall]() Original publisher: [Read original article]() Author: Atharva Deosthale Published: 2026-09-04T00:00:00Z Content type: tutorial Language: en Sources: [Appwrite Blog]() Topics: [Appwrite](), [Firewall](), [Algorithms](), [HTTP](), [client]() Tags: [firewall](), [http](), [rate-limiting](), [security](), [strategy]() ### AI overview This article explains the fixed window, sliding window, and token bucket rate-limiting strategies supported by Appwrite Firewall. It compares how they handle bursts and time-window boundaries, describes IP- and User ID-based limits, and explains how to choose a strategy. ### Source excerpt Appwrite Firewall rate limit rules support three strategies. Learn how fixed window, sliding window, and token bucket work, where each one breaks down, and how to pick the right one for your traffic. ## Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures DevFeed: [Shared Host Ephemeral Port Exhaustion Caused Overnight Job Failures]() Original publisher: [Read original article]() Author: PULKIT GARG Published: 2026-08-11T05:58:23Z Content type: article Language: en Sources: [Housing.com]() Topics: [ephemeral ports](), [incident](), [Kernel]() Tags: [incident](), [port](), [production-issue](), [rate-limiting](), [ruby-on-rails](), [tcp]() ### AI overview An engineering incident report explains how a neighboring bulk job exhausted the shared operating system's ephemeral TCP port pool, causing scheduled background jobs to fail until the temporary traffic pressure subsided. ### Source excerpt A neighbor's bulk job drained every ephemeral port on a shared box. Twice. Here's the one kernel setting that would have stopped it -- and the architecture that makes it a non-issue. At 1:38 AM, one of our background-job services started failing. Scheduled jobs -- the nudges and reminders we send users overnight -- began throwing an error most engineers rarely see: Errno::EADDRNOTAVAIL -- Cannot assign requested address Not "connection refused." Not "timeout." Cannot assign requested address. The machine wasn't saying the other end was down. It was saying it had run out of addresses to call from. Here's the strange part: we hadn't deployed anything. Our code was untouched for days. And by ~3 AM it healed itself, with nobody doing a thing. Two nights later, same window, it happened again. The bug wasn't in our service. It was in a service we don't own -- and don't even talk to. Act 1: A crime scene with no suspect ~7,800 job executions failed across the two nights. The first night slipped in under the alerting threshold entirely -- we only found it in the errors inbox after the fact. Everything about it was confusing: Our service hadn't changed. The internal APIs we call were all healthy. It happened in a tight window (~1:30-3:00 AM), then vanished. No human fixed it. It just... stopped. An outage that fixes itself is telling you something important: the thing that broke wasn't yours, and the pressure that caused it was temporary. Act 2: The noisy neighbor That service doesn't run on its own machine. It shares one box with about ten other apps -- a normal, cost-efficient setup. What's easy to forget is what they silently share: not just CPU and memory, but the operating system's ephemeral port pool. Quick refresher. Every time a program opens an outbound TCP connection, the OS assigns it a temporary "ephemeral" source port. That pool is finite -- by default, roughly 28,000 ports. And on a shared box, every app draws from the same pool. Ephemeral ports are an unmonitored, multi ## Palantir's Elasticsearch reindexing system supports online index rebuilds DevFeed: [Palantir's Elasticsearch reindexing system supports online index rebuilds]() Original publisher: [Read original article]() Author: Alexandre Zajac Published: 2026-06-15T15:30:53Z Content type: article Language: en Sources: [Hungry Minds]() Topics: [elasticsearch](), [Software Engineering](), [Database](), [observability]() Tags: [architecture](), [dashboards](), [database](), [elasticsearch](), [implementation](), [observability](), [parallel](), [rate-limiting]() ### AI overview The article describes Palantir's Elasticsearch reindexing system, which rebuilds large search indices while live traffic continues. It uses shadow indices, parallel database-to-index pipelines, multidimensional rate limiting, crash-safe state tracking, and support for multiple clusters. ### Source excerpt PLUS: Claude skills guide 👨💻, Call queue architecture ⚡, when NOT to use Kafka 👨💻 ## Post Mortem: HTTP Request Smuggling Vulnerability DevFeed: [Post Mortem: HTTP Request Smuggling Vulnerability]() Original publisher: [Read original article]() Author: Julien Portalier Published: 2026-05-26T00:00:00Z Content type: article Language: en Sources: [Crystal]() Topics: [Post Mortem](), [vulnerability](), [Crystal](), [HTTP](), [Security](), [Exploit]() Tags: [2026](), [access-control](), [http](), [post-mortem](), [rate-limiting](), [security](), [server](), [vulnerability]() ### AI overview This post-mortem describes an HTTP request smuggling vulnerability in Crystal's HTTP server. The parser mishandled requests containing conflicting framing headers, allowing request injection between a reverse proxy and a Crystal server under specific proxy conditions. The issue was patched in Crystal 1.20.0 and 1.19.2. ### Source excerpt On 12 April 2026, we received a vulnerability report regarding an HTTP request smuggling vulnerability in HTTP::Server. ## Rate-limit downstream APIs with separate Task Queues DevFeed: [Rate-limit downstream APIs with separate Task Queues]() Original publisher: [Read original article]() Author: Cecil Phillip Published: 2026-05-25T00:00:00Z Content type: tutorial Language: en Sources: [Temporal Blog]() Topics: [rate-limiting](), [API](), [Concurrency](), [configuration]() Tags: [apis](), [concurrency](), [configuration](), [queues](), [rate-limiting](), [service](), [temporal-concepts]() ### AI overview This tutorial explains how to use separate Temporal Task Queues with global and optional per-Worker rate limits, plus concurrency limits, to keep Activities within downstream API quotas and help prevent 429 errors and account issues. ### Source excerpt Stop hitting 429s on downstream APIs. Use rate-limited Temporal Task Queues to keep Activities under SendGrid, Stripe, and OpenAI quotas. ## Replay '26: My introduction to Temporal DevFeed: [Replay '26: My introduction to Temporal]() Original publisher: [Read original article]() Author: Jap Singh Published: 2026-05-21T00:00:00Z Content type: opinion Language: en Sources: [Temporal Blog]() Topics: [Development](), [Hackathon](), [Artificial Intelligence](), [rate-limiting](), [Orchestration](), [Go Language](), [Java](), [Python]() Tags: [ai](), [company](), [conference](), [experience](), [hackathon](), [orchestration](), [rate-limiting](), [software](), [temporal-voices](), [vibe-coding]() ### AI overview A new Temporal employee recounts attending Replay '26 during their first week at the company. The article highlights developer discussions about AI-heavy workflows, rate limiting, enterprise use cases, clinical-trial monitoring, and workshops in Java, Go, and Python. ### Source excerpt Jap Singh joined Temporal and found himself at Replay '26 in his first week. His experience changed his view on the company. ## How Agentic AI Can Bypass the Application Layer's Database Protections DevFeed: [How Agentic AI Can Bypass the Application Layer's Database Protections]() Original publisher: [Read original article]() Author: flashdba Published: 2026-05-11T11:06:56Z Content type: opinion Language: en Sources: [flashdba]() Topics: [Architecture & Design](), [Artificial Intelligence](), [Database]() Tags: [agentic](), [agentic-ai](), [ai](), [ai-agents](), [architecture](), [business-logic](), [cloud](), [database](), [databases](), [databases-and-agentic-ai](), [inferencing](), [performance](), [rate-limiting]() ### AI overview The article argues that application layers unintentionally protect databases through query abstraction, input validation, rate limiting, and human-oriented traffic patterns. Direct database access by agent frameworks can bypass these protections, allowing unconstrained queries and exposing the database to unfamiliar load and access patterns. ### Source excerpt The application layer was never designed as a database security boundary - but it acted as one. Agentic AI removes that protection, via bypass or overwhelm, and the database is left exposed. ## SSH Port 22: Custom Ports, Port Forwarding Security, and Production SSH Hardening DevFeed: [SSH Port 22: Custom Ports, Port Forwarding Security, and Production SSH Hardening]() Original publisher: [Read original article]() Author: info@goteleport.com (Matt Keib) Published: 2026-05-01T00:00:00Z Content type: tutorial Language: en Sources: [Teleport]() Topics: [Security](), [OpenSSH](), [ssh](), [Authentication](), [rate-limiting](), [Authorization](), [configuration]() Tags: [configuration](), [hardening](), [port](), [rate-limiting](), [security](), [server](), [ssh](), [tcp](), [tcp-handshake]() ### AI overview This article explains that SSH port 22 is a historical TCP entry point with no inherent cryptographic or authentication significance. It covers port forwarding risks, cryptographic and authentication configuration, rate limiting, and production SSH hardening. ### Source excerpt Learn about SSH port 22, its limitations, port forwarding security, and how to harden production SSH. ## Agentic AI removes human safeguards from enterprise data feedback loops DevFeed: [Agentic AI removes human safeguards from enterprise data feedback loops]() Original publisher: [Read original article]() Author: flashdba Published: 2026-04-20T22:04:35Z Content type: opinion Language: en Sources: [flashdba]() Topics: [Artificial Intelligence](), [data-architecture](), [data-engineering](), [rate-limiting](), [audit trail]() Tags: [agentic](), [agentic-ai](), [ai](), [audit-trail](), [cloud](), [data-architecture](), [data-engineering](), [databases](), [databases-and-agentic-ai](), [inferencing](), [performance](), [rate-limiting]() ### AI overview This opinion article argues that enterprise data architectures traditionally relied on human involvement as an implicit safeguard. Delays, approvals and handoffs helped absorb errors, create audit points and limit the speed of changes. Agentic AI can close the feedback loop at machine speed, potentially removing those protections along with the human decision point. ### Source excerpt Classic enterprise data architecture had an implicit safeguard built into it. The human in the loop provided error absorption, audit accretion and natural rate-limiting - none of which were ever specified. Agentic AI removes the human. It removes all of those protections simultaneously. ## Securely connect Claude Code to Postgres via MCP DevFeed: [Securely connect Claude Code to Postgres via MCP]() Original publisher: [Read original article]() Published: 2026-04-13T13:24:20Z Content type: tutorial Language: en Sources: [Learn on Tailscale]() Topics: [Model Context Protocol](), [Claude Code](), [Database](), [Access Control](), [audit]() Tags: [access-control](), [audit](), [claude-code](), [codex](), [cursor](), [health-checks](), [mcp](), [oauth](), [postgres](), [rate-limiting]() ### AI overview A practical guide to connecting Claude Code, Cursor, and Codex to Postgres through MCP. It covers quick local setup, comparing Postgres MCP servers, and securing team or production deployments with least-privilege credentials, environment variables, access controls, audit trails, and related governance features. ### Source excerpt Set up Postgres MCP for Claude Code, Cursor, Codex fast, and see how to handle credentials, access control, and audit trails. ## What is the BFF Pattern? DevFeed: [What is the BFF Pattern?]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-04-07T08:41:56Z Content type: tutorial Language: en Sources: [System Design Codex]() Topics: [BFF](), [Amazon API Gateway](), [backends](), [client](), [interface](), [resiliency](), [Orchestration](), [rate-limiting]() Tags: [api-gateway](), [authentication](), [backends](), [bff](), [cache-control](), [client](), [decoupling](), [mobile](), [rate-limiting](), [resiliency]() ### AI overview The article explains the Backends-for-Frontends (BFF) pattern, in which dedicated API gateways serve different client types such as web browsers, mobile apps, and public or partner APIs. It describes how BFFs tailor APIs, isolate client-specific logic, and support functions including rate limiting, authentication, header sanitization, and cache control. It also discusses benefits such as resiliency, client-specific optimization, and faster development, along with drawbacks including code duplication and increasing complexity. ### Source excerpt And when do you need it? ## How to Charge for API Access: A Developer's Guide DevFeed: [How to Charge for API Access: A Developer's Guide]() Original publisher: [Read original article]() Author: Ayush Agarwal Published: 2026-03-25T00:00:00Z Content type: tutorial Language: en Sources: [Dodo Payments Blog]() Topics: [API](), [Software as a service](), [API keys]() Tags: [api](), [apis](), [billing](), [developer](), [guide](), [how-to](), [integration](), [payments](), [rate-limiting](), [saas](), [tax](), [usage-based-billing]() ### AI overview A developer guide explains three ways to monetize API access: pay-per-call billing, subscription tiers with rate limits, and prepaid credits. It also covers customer metering, checkout, idempotency keys, entitlement management, tax compliance, and failed-payment handling. ### Source excerpt Step-by-step guide to monetizing your API with pay-per-call, subscription tiers, or credit-based billing. Includes metering, checkout integration, and usage tracking. ## How AI firewalls protect production applications from prompt injection, data leakage, and excessive usage DevFeed: [How AI firewalls protect production applications from prompt injection, data leakage, and excessive usage]() Original publisher: [Read original article]() Author: Alex Ewerlöf Published: 2026-03-15T23:51:29Z Content type: tutorial Language: en Sources: [Alex Ewerlof Notes]() Topics: [Firewall](), [Security](), [prompt injection](), [LLMs](), [rate-limiting](), [pii]() Tags: [architecture](), [firewall](), [llms](), [pii](), [prompt-injection](), [rate-limiting](), [security]() ### AI overview This tutorial explains AI firewalls, or AI gateways, as reverse proxies with AI-focused inspection between an application backend and an inference provider. It covers ingress attacks such as prompt injection, egress risks including PII and secrets, rate limiting to control costs, latency considerations, implementation trade-offs, and layered defenses. ### Source excerpt How to protect your AI application in production against new classes of attacks ## AI Slop: A Slack API Rate Limiting Disaster DevFeed: [AI Slop: A Slack API Rate Limiting Disaster]() Original publisher: [Read original article]() Author: Daniel Doubrovkine (dblock@dblock.org) Published: 2026-03-12T00:00:00Z Content type: article Language: en Sources: [Daniel Doubrovkine]() Topics: [Slack](), [API](), [Code]() Tags: [ai](), [api](), [async](), [code](), [concurrent](), [distributed-system](), [rate-limiting](), [retry](), [script](), [slack]() ### AI overview The article examines an AI-generated cleanup job for closing old Slack group DM conversations. Because Slack's conversations.close endpoint has a global rate limit of one request per second, the implementation could exhaust the limit and disrupt other API calls. The author describes mitigating the issue with scheduled execution, an opt-in setting, a slow-drain script, and limiting the number of DMs closed concurrently. ### Source excerpt Yesterday I described AI-generated code as "plausible-looking, locally coherent, globally wrong." Here's a concrete example from my own codebase. I needed a cleanup job to close old Slack group DM conversations in my slack-sup2 app. The AI-generated solution looked perfectly reasonable: def close_old_sups! return 0 unless sup_close old_sups = sups.where(conditions) old_sups.each(&:close!) old_sups.count end def close! return unless conversation_id return if closed_at logger.info "Closing DM channel #{conversation_id}..." slack_client.conversations_close(channel: conversation_id) update_attributes!(closed_at: Time.now.utc) end This code looks pretty great and completely breaks the app. Slack's API has a global rate limit of 1 request per second for the conversations.close endpoint. So, when this job runs against a workspace with hundreds of old conversations, it immediately hits the rate limit. Worse, because rate limits are global across all endpoints, it takes down the entire application. Every other API call -- posting messages, fetching user info, everything -- starts failing. I asked AI to address this. It made the fix catastrophically worse. def close! # ... existing code ... begin slack_client.conversations_close(channel: conversation_id) rescue Slack::Web::Api::Errors::TooManyRequests => e sleep_time = e.retry_after || 60 sleep(sleep_time) retry end # ... rest of method ... end In socketry/async, sleep() blocks the entire fiber and prevents other concurrent operations from executing. You should use Async::Task.sleep() instead, but that still doesn't solve the fundamental architectural problem of making hundreds of sequential API calls. What made this particularly insidious is that the assistant wrote some pretty professional-looking code and seemingly handled obvious edge cases. Yet, it failed to consider the distributed system constraints or global invariants. The rate limiting problem wasn't visible in the local scope of the method - it was a system-wide conc ## Announcing the AI Gateway Working Group DevFeed: [Announcing the AI Gateway Working Group]() Original publisher: [Read original article]() Author: The Kubernetes Authors Published: 2026-03-09T00:00:00Z Content type: release Language: en Sources: [Kubernetes Contributors Blog]() Topics: [Kubernetes](), [networking](), [AI Infrastructure](), [Artificial Intelligence](), [API]() Tags: [ai-gateway](), [ai-infrastructure](), [anomaly-detection](), [architecture](), [caching](), [kubernetes](), [networking](), [payload](), [prompt-injection](), [rag](), [rate-limiting](), [routing]() ### AI overview The Kubernetes community has formed the AI Gateway Working Group to develop standards, declarative APIs, and best practices for networking infrastructure that supports AI workloads. The group's proposals address policy enforcement, payload processing, routing, caching, guardrails, and RAG integration. ### Source excerpt The community around Kubernetes includes a number of Special Interest Groups (SIGs) and Working Groups (WGs) facilitating discussions on important topics between interested contributors. Today, we're excited to announce the formation of the AI Gateway Working Group , a new initiative focused on developing standards and best practices for networking infrastructure that supports AI workloads in Kubernetes environments. What is an AI Gateway? In a Kubernetes context, an AI Gateway refers to network gateway infrastructure (including proxy servers, load-balancers, etc.) that generally implements the Gateway API specification with enhanced capabilities for AI workloads. Rather than defining a distinct product category, AI Gateways describe infrastructure designed to enforce policy on AI traffic, including: Token-based rate limiting for AI APIs. Fine-grained access controls for inference APIs. Payload inspection enabling intelligent routing, caching, and guardrails. Support for AI-specific protocols and routing patterns. Working group charter and mission The AI Gateway Working Group operates under a clear charter with the mission to develop proposals for Kubernetes Special Interest Groups (SIGs) and their sub-projects. Its primary goals include: Standards Development: Create declarative APIs, standards, and guidance for AI workload networking in Kubernetes. Community Collaboration: Foster discussions and build consensus around best practices for AI infrastructure. Extensible Architecture: Ensure composability, pluggability, and ordered processing for AI-specific gateway extensions. Standards-Based Approach: Build on established networking foundations, layering AI-specific capabilities on top of proven standards. Active proposals WG AI Gateway currently has several active proposals that address key challenges in AI workload networking: Payload Processing The payload processing proposal addresses the critical need for AI workloads to inspect and transform full HTTP request a ## Firewalld, UFW y nftables en Linux DevFeed: [Firewalld, UFW y nftables en Linux]() Original publisher: [Read original article]() Author: Antonio Pérez Published: 2026-01-21T00:00:00Z Content type: tutorial Language: es Sources: [tengoping.com]() Topics: [Firewall](), [Linux](), [centos](), [Debian](), [Fail2ban]() Tags: [centos](), [debian](), [fail2ban](), [firewall](), [linux](), [rate-limiting](), [ssh]() ### AI overview A practical Spanish-language guide to managing Linux firewall rules with firewalld, UFW, and nftables. It explains runtime versus permanent rules, rich rules and NAT, rate limiting, SSH protection, and persistence after reboot, with warnings about avoiding lockout during remote administration. ### Source excerpt Firewalld, UFW y nftables: reglas permanentes vs runtime, rate limiting, persistencia tras reinicio y migración desde iptables. ## hybrid quota-linear rate limiter DevFeed: [hybrid quota-linear rate limiter]() Original publisher: [Read original article]() Published: 2026-01-13T00:12:01Z Content type: article Language: en Sources: [Tony Finch's blog]() Topics: [rate-limiting](), [Algorithms]() Tags: [algorithm](), [quotas](), [rate-limiting]() ### AI overview The article explores a hybrid quota-linear rate limiter intended to enforce request quotas more precisely within a time window while limiting storage costs and avoiding bursty client behavior. It compares linear rate limiting with fixed-window quota resets and notes trade-offs, including throttling response time and burstiness. ### Source excerpt A while back I wrote about the linear rate limit algorithms leaky bucket and GCRA. Since then I have been vexed by how common it is to implement rate limiting using complicated and wasteful algorithms (for example). But linear (and exponential) rate limiters have a disadvantage: they can be slow to throttle clients whose request rate is above the limit but not super fast. And I just realised that this disadvantage can be unacceptable in some situations, when it's imperative that no more than some quota of requests is accepted within a window of time. In this article I'll explore a way to enforce rate limit quotas more precisely, without undue storage costs, and without encouraging clients to oscillate between bursts and pauses. However I'm not sure it's a good idea. linear reaction time fixed window quota resets hybrid quota-linear algorithm discussion opinion linear reaction time How many requests does a linear rate limiter allow before throttling? The parameters for a rate limiter are: q, the permitted quota of requests w, the accounting time window So the maximum permitted rate is q/w. Let's consider a client whose rate is some multiple a > 1 of the permitted rate (a for abuse factor) c = a * q/w I'll model the rate limiter as a token bucket which starts off with q tokens at time 0. The bucket accumulates tokens at the permitted rate and the client consumes them at its request rate. (It is capped at q tokens but we can ignore that detail when a > 1.) b(t) = q + t*q/w - t*a*q/w The time taken for n requests is t(n) = n/c = (n*w) / (a*q) After n requests the bucket contains b(n) = q + n/a - n The rate limter throttles the client when the bucket is empty. b(t) = 0 = q + t * (1 - a) * q/w 0 = 1 - t * (a - 1) / w t = w / (a - 1) b(n) = 0 = q + n * (1/a - 1) 0 = q - n * (a - 1) / a n = q * a / (a - 1) For example, if the client is running at twice the permitted rate, a=2, they will be allowed q*2 requests within w seconds before they are throttled. That's a bit slow. T ## Proxy inverso con Nginx: guía práctica DevFeed: [Proxy inverso con Nginx: guía práctica]() Original publisher: [Read original article]() Author: Antonio Pérez Published: 2026-01-09T00:00:00Z Content type: tutorial Language: es Sources: [tengoping.com]() Topics: [nginx](), [proxy](), [rate-limiting](), [let's encrypt](), [rhel](), [SELinux]() Tags: [let-s-encrypt](), [nginx](), [proxy](), [rate-limiting](), [rhel](), [selinux](), [ssl]() ### AI overview A practical Spanish-language guide to using Nginx as a reverse proxy. It covers routing traffic to internal applications, HTTPS with Let's Encrypt, load balancing, upload and proxy timeout settings, request-rate limiting, gzip compression, security headers, and the 502 issue associated with SELinux on RHEL. ### Source excerpt Nginx como proxy inverso: subidas de archivos grandes, timeouts, rate limiting, gzip y el clásico 502 por SELinux en RHEL. ## Building a Transparent Keyserver DevFeed: [Building a Transparent Keyserver]() Original publisher: [Read original article]() Author: Filippo Valsorda Published: 2025-12-19T14:03:18Z Content type: tutorial Language: en Sources: [Filippo Valsorda]() Topics: [systems](), [rate-limiting](), [Go Language](), [Server](), [SQLite](), [Authentication](), [Tooling](), [Command-line interface]() Tags: [api](), [authentication](), [building](), [cli](), [go](), [privacy](), [rate-limiting](), [server](), [sqlite](), [tooling](), [transparency-log]() ### AI overview This tutorial builds a centralized keyserver for looking up age public keys. It applies transparency-log technology to help keep the operator accountable and prevent surreptitious injection of malicious keys while protecting user privacy. The implementation uses a Go server, SQLite database, APIs, email authentication, a CAPTCHA, and a Go CLI. ### Source excerpt We apply a transparency log to a centralized keyserver step-by-step, in less than 500 lines, with privacy protections, anti-poisoning, and witness cosigning. ## Securing a retail AI endpoint from abuse for virtual try on DevFeed: [Securing a retail AI endpoint from abuse for virtual try on]() Original publisher: [Read original article]() Author: Alexander Nohe Published: 2025-11-11T00:00:00Z Content type: tutorial Language: en Sources: [Firebase Blog]() Topics: [Artificial Intelligence](), [Firebase](), [Authentication](), [Back end](), [Code](), [cURL]() Tags: [ai](), [app-check](), [attestation](), [authentication](), [backend](), [code](), [curl](), [devices](), [firebase](), [generation](), [genkit](), [how-to](), [image](), [model](), [rate-limiting](), [retail](), [server](), [token]() ### AI overview A tutorial on protecting a Firebase AI endpoint for a virtual try-on application. It explains using App Check, replay-protected tokens, authentication, and rate limiting to reduce unauthorized access, replayed requests, and excessive generation costs. ### Source excerpt Learn how to protect expensive AI features from abuse using Firebase App Check, Authentication, and rate limiting to ensure only legitimate users can access them. [Next page]()