What it is
A budget per source per window: so many connections per second from one address, so many joins per minute from one network, so many status requests before the rest are served from cache. Exceed the budget and the excess is dropped or delayed. It is cheap to evaluate, which matters when the evaluation itself must survive the flood.
Why it matters for Minecraft
It removes the entire class of unsophisticated attack at almost no cost, and unsophisticated attacks are the overwhelming majority. Most of what a public server receives is a rented flood from a handful of sources, and a sensible per-source budget ends it without anyone noticing.
Where it structurally fails
Two places, both worth knowing. Distributed attacks: ten thousand sources each staying politely under the threshold produce an enormous aggregate while no individual source ever trips. And bypass bots, which self-throttle deliberately. In both cases the rate is fine and the server still falls over — which is why rate limiting needs to sit alongside verification rather than instead of it. Limits that adapt under Under Attack Mode help, but the blind spot is inherent.
Common questions
What is a good join rate limit for a Minecraft server?+
It depends on your legitimate peak, which is the point — a limit tuned below a busy restart will kick your own returning players. Adaptive limits that tighten only when attack indicators rise avoid having to pick one number for both situations.
Is rate limiting enough on its own?+
For crude floods, often. For anything distributed or deliberately paced, no — those are the cases it is structurally unable to see, and they are the cases that take servers down.