Rate Limiting

Software Engineering / 21 Sep 2026 / 6 min read

Token Buckets Preserve Burst Capacity Without Removing Rate Bounds

Token Buckets Preserve Burst Capacity Without Removing Rate Bounds A fixed requests-per-second ceiling treats a brief spike and a sustained flood as the same event. That can be too rigid for services whose callers naturally arrive in clusters. A token bucket separates two constraints: the long-run admission rate and the amount of burst traffic the service is willing to absorb. The model has two parameters. The bucket capacity B is the maximum number of tokens that can accumulate. The refill rate r adds tokens per unit of time, up to B. A request consumes tokens according to its configured cost. If enough tokens are present, the request proceeds; otherwise it is rejected, delayed, or handled by another explicit policy.

Software Engineering Distributed Systems

Software Engineering / 20 Sep 2026 / 6 min read

Token Buckets Separate Sustained Rate from Burst Capacity

A rate limit expressed only as “100 requests per second” leaves an important policy question open. Can a client send 100 requests at the first instant of each second, or must those requests be spread evenly? A token bucket makes that distinction explicit by separating sustained rate from burst capacity. The limiter maintains a balance of tokens up to a fixed capacity. Tokens arrive at a configured refill rate. An operation is admitted only when enough tokens are available, and admission deducts its cost from the balance. Idle time accumulates capacity for a later burst, but never beyond the bucket limit.

Software Engineering Rate Limiting

Cybersecurity / 12 Sep 2026 / 9 min read

Throttle Authentication Attempts Without Locking Out Users

Password authentication exposes a public decision point: a client submits a claimed identity and a secret, then the server accepts or rejects the pair. Attackers can automate that decision point at a scale no human user can match. A simple request limit helps, but authentication traffic has unusual constraints. A limit tied only to an IP address can punish thousands of legitimate users behind one gateway. A limit tied only to an account lets an attacker deliberately block a victim from signing in. A permanent account lock can turn a guessing defense into a denial-of-service primitive.

Cybersecurity Authentication

Software Engineering / 10 Sep 2026 / 10 min read

Token Bucket Rate Limiting for Controlled Bursts

Token Bucket Rate Limiting for Controlled Bursts A service may handle 100 requests per second comfortably on average while still needing to accept a short burst of 300 requests after a client reconnects. A rigid per-second limit treats those situations as the same problem: once the current window is full, otherwise acceptable work is rejected. Token bucket rate limiting gives you a more useful control. It separates two decisions: how quickly permission to do work is replenished and how much permission may accumulate for a burst. Once you understand those two numbers, you can reason about the limiter without depending on a particular library or platform.

Software Engineering Reliability

Cybersecurity / 10 Sep 2026 / 10 min read

Rate Limit Login Attempts Without Creating Easy Lockouts

A login endpoint has to accept wrong passwords. Users mistype them, password managers can hold stale credentials, and old devices sometimes retry automatically. An attacker can use the same interface to make thousands of guesses unless the application limits how quickly authentication can be attempted. The obvious fix is to lock an account after several failures. That slows guessing, but it creates another problem: anyone who knows a username may be able to keep that user locked out by deliberately submitting bad passwords.

Cybersecurity Authentication

Cybersecurity / 10 Sep 2026 / 10 min read

Rate Limit Login Attempts Without Creating a Lockout Weapon

A login endpoint has an awkward property: before authentication succeeds, it must accept requests from people whose identity it hasn’t proved yet. That makes it a natural target for automated password guessing. If the endpoint allows unlimited attempts, an attacker gets unlimited opportunities to try credentials. If it permanently locks an account after a few failures, the attacker may be able to lock out the legitimate user instead. Login rate limiting is the middle ground. It reduces how quickly repeated authentication attempts can be made, but the design matters. A useful limiter needs to constrain attacks aimed at one account, attacks coming from one source, and distributed attacks without turning every false positive into a long outage.

Cybersecurity Authentication

Cybersecurity / 09 Sep 2026 / 10 min read

Rate Limit by the Resource an Attacker Can Exhaust

A rate limit can look effective in testing and still fail against the abuse it was meant to control. The usual reason is not the counter or the algorithm. It is the key used to group requests. Suppose a password-recovery endpoint allows five requests per hour from each source address. That may slow one client, but it does not directly protect a user’s mailbox from receiving hundreds of recovery messages sent through many source addresses. The resource under pressure is the destination account or delivery channel, while the limit is counting something else.

Cybersecurity Rate Limiting

Cybersecurity / 08 Sep 2026 / 9 min read

Throttle Authentication Failures Without Creating a Lockout Weapon

A login endpoint has to reject wrong credentials, but rejection alone does not control how quickly someone can keep trying. If an application accepts thousands of password attempts against the same account with no meaningful slowdown, an attacker gets many chances to guess a valid password. A simple permanent lock after a few failures creates a different problem: anyone who knows a username may be able to lock out its owner on demand.

Cybersecurity Authentication

Cybersecurity / 06 Sep 2026 / 11 min read

Rate-Limit Login Attempts by Account and Source

A login endpoint may verify passwords correctly and still give an attacker too many chances to guess them. If failed attempts can be repeated quickly, weak or reused passwords become easier to test through the same interface legitimate users use. A common response is to add a rate limit. The difficult part is choosing what the limit follows. Limiting only an IP address misses distributed attempts from many sources. Limiting only an account lets one source spread attempts across many accounts. Combining the IP address and account into one key looks stricter, but creates a fresh allowance for every pair.

Cybersecurity Authentication

Cybersecurity / 05 Sep 2026 / 9 min read

Throttle Login Attempts Without Making Lockout a Weapon

A login endpoint must accept failed passwords. That necessary behavior also gives an attacker a place to make repeated guesses or test credentials stolen from another service. If attempts are effectively unlimited, automation turns each individual login failure into part of a much larger search. A tempting response is to lock an account after a small number of failures. That slows guessing against the account, but it creates another problem: anyone who knows the username may be able to trigger the lockout. A control intended to protect authentication can become a denial-of-service mechanism against legitimate users.

Cybersecurity Authentication

Cybersecurity / 04 Sep 2026 / 10 min read

Design Rate Limits Around Security Identities

A rate limit sounds simple: allow only a certain number of requests during a period. The difficult security question is not the number. It is what you count together. Suppose a login endpoint allows five failed attempts per minute from each IP address. That can slow one client, but an attacker using many addresses can still make many guesses against the same account. Change the rule to five failures per account and another problem appears: anyone who knows a username may be able to keep that user’s account throttled.

Cybersecurity Rate Limiting

Cybersecurity / 03 Sep 2026 / 6 min read

Limit Authentication Abuse with Layered Rate Controls

Authentication endpoints attract automation because each request can test credentials, probe account state, or trigger expensive verification work. Rate controls reduce the speed and value of this abuse, but a single requests-per-minute limit is rarely enough. A useful design combines several signals and responses. The objective is to make abusive behaviour slower and noisier while keeping legitimate users able to recover from mistakes, shared networks, and temporary failures. Protect the whole authentication surface Login is only one part of authentication. Review every endpoint that can verify, change, or recover identity state, including:

Cybersecurity Authentication

Go / 01 Sep 2026 / 7 min read

Token Bucket Rate Limiting in Go

Rate limiting protects a service from traffic spikes, accidental client loops, and workloads that consume more resources than the system can safely handle. A useful limiter should do more than enforce a fixed request count: it should allow small bursts while keeping the long-term request rate bounded. The token bucket algorithm provides exactly that behavior. This guide implements a small, concurrency-safe token bucket using only Go’s standard library and then shows how to use it in an HTTP service.

Golang Rate Limiting