What is rate limiting? How it guards a question box from mass posting
Updated: 2026-05-06 · 3 min read
Why posting frequency needs to be limited
Not just question boxes, but any web service that lets users freely send data carries the risk of mass-posting attacks. If a malicious user or a bot sends hundreds or thousands of posts in a short time, 2 problems may arise.
First, the question box owner's dashboard gets flooded with spam. Real questions get buried under piles of spam and can't be found. The owner is forced to delete the spam one item at a time, and may come to hate running the question box at all.
Second, the server comes under excessive load. When hundreds of requests per second pile up, they go beyond what the server can handle, and access for legitimate users may slow down too, or in the worst case, the service may stop. This is one form of DDoS (Distributed Denial of Service) attack.
Rate limiting is a mechanism that holds back these problems with a simple approach: setting an upper limit on how often people can post.
How rate limiting works: the token bucket idea
There are several ways to implement rate limiting, but one model that's easy to grasp intuitively is the "token bucket."
Imagine a bucket (a container) with tokens (coins) inside. Each time you send 1 question, 1 token is used up. Tokens are refilled automatically at a steady rate. When the bucket is empty, you can't post until tokens are refilled.
Suppose we limit posts from the same IP address to 5 per minute. The bucket holds up to 5 tokens, and it's refilled up to 5 tokens every minute. At the pace a person sends questions (from tens of seconds to a few minutes per question), the tokens will hardly ever run out. But if a bot tries to send 100 posts in 1 second, the tokens run out after the first 5, and the remaining 95 are rejected.
The strength of this mechanism is that it has almost no effect on legitimate users while making it easier to block malicious mass posting.
Limits based on IP address and their weaknesses
Rate limiting needs to identify "who a post is from." In a service like a question box, where you can post without creating an account, one approach is to use the sender's IP address as the identifier. When posts from the same IP address go over the limit, the extra posts are rejected.
Limits based on IP address have weaknesses too. First, multiple users who share the same network (office Wi-Fi or school Wi-Fi) end up posting from the same IP address. In that case, if one person posts up to the limit, other users on the same network may also be unable to post for a while. That said, the limit is set with normal use in mind, so the situations where this becomes a problem are probably limited.
Second, if an attacker changes their IP address often by using a VPN or a proxy, they can get around rate limiting. Each time the IP address changes, a new bucket is assigned, so the limit resets.
One way to make up for this weakness is not to use rate limiting on its own, but to combine it with Proof of Work and honeypot fields. Even if someone changes their IP address to get around rate limiting, each post still costs Proof of Work computation, and bot detection by the honeypot still works. As one layer of defense in depth, rate limiting plays an important role.
If you hit the rate limit
It's rare for a legitimate user to hit the rate limit, but it isn't impossible. It can happen if you send questions to several question boxes one after another in a short time, or if you end up tapping the Send button over and over.
When you hit the rate limit, the server returns the status code HTTP 429 (Too Many Requests). The message "Too many posts. Please wait a moment" appears on the screen.
What to do is simple. Wait about 1 minute, then send again. The limit is lifted as time passes, so just waiting gets you back to being able to post. The question you typed doesn't disappear, so you don't need to type it again.
The basic idea is to set the posting limit at a level that's hard to reach at the pace people normally send questions. Sending 1 question takes tens of seconds to think of what to write, type it, and send it, so in normal use you rarely touch the limit.
The design thinking behind rate limiting: balancing convenience and security
One of the hard parts of designing rate limiting is setting the threshold (the upper limit). If the threshold is too strict, it hurts convenience for legitimate users. If it's too loose, it becomes harder to stop attacks.
The threshold is set based on how fast humans act. The time it takes a person to send 1 question is tens of seconds, even for a short, routine question. If the limit is placed at "a level that even the fastest human pace just barely fails to reach," convenience for legitimate users probably won't suffer. Bots, on the other hand, try to send tens to hundreds of posts per second, so even a limit at this level greatly lowers their posting speed.
Rate limiting and Proof of Work complement each other. Proof of Work holds back mass posting by imposing "a computing cost per post," while rate limiting directly limits "the number of posts per unit of time." Even if someone solves Proof of Work quickly with a high-performance GPU, as long as there's rate limiting, their posting frequency hits a ceiling at the limit. On the other hand, even if someone changes their IP address to get around rate limiting, each post still needs Proof of Work computation.
With this double constraint, attackers have to bear both a "computing cost" and a "time cost," which makes spam less worth the cost. Rather than stopping attacks completely, we think a realistic defense strategy is to raise the cost of attacking until it no longer pays off. Rate limiting is an important part of that strategy.