Roblox Safe Rate Limiter Against RemoteEvent Spam
ESCOPO
This prompt creates a professional rate limiting system for Roblox experiences that receive many client requests via RemoteEvents or RemoteFunctions. The result uses a token bucket model configurable by action, allowing temporary burst control, refill rate, progressive penalties, and temporary blocks without trusting the client.
Ideal for games with combat, inventory, shops, abilities, crafting, trading, teleportation, or any mechanic exposed through remotes. The prompt requires server-side validation, memory cleanup when players leave, optional logs for debugging, and a clear API to integrate the limiter into existing handlers.
Just provide the real Explorer structure, the RemoteEvents used, and the desired limits. The AI will return a commented Luau ModuleScript, ready to paste into Roblox Studio, plus safe integration examples and an objective test plan.
Conteudo
Prompt principal
Act as a senior Roblox Luau developer, specializing in client-server architecture security, scalability, and abuse prevention through RemoteEvents/RemoteFunctions. Generate a server-authoritative rate limiting system, based on token bucket, adapted to the real context of my game.
Before writing the code, use the context I will fill in below. If any field is missing, do not invent object names or assume a non-existent hierarchy: clearly state which values need to be replaced and use example names that are clearly marked. Prioritize delivering a functional solution ready for adaptation, without asking follow-up questions.
MY GAME CONTEXT (I will fill in before sending):
- Path/folder of the RemoteEvents and RemoteFunctions in Explorer: [EX.: ReplicatedStorage.Remotes]
- List of remotes to protect, type, and purpose: [EX.: AttackEvent - RemoteEvent - attack; BuyItem - RemoteFunction - purchase]
- Desired limit per action: [EX.: AttackEvent: 8 per second, burst of 12; BuyItem: 2 per second, burst of 3]
- Policy when exceeded: [EX.: ignore request, warn in log, block for 10 seconds after 5 violations]
- Server systems that already handle these remotes and their paths: [FILL IN]
- If I should use DataStore, kick, ban, or analytics: [FILL IN; default: do not use]
- Game-specific version/features that need to be preserved: [FILL IN]
THE MAIN ARTIFACT MUST be exactly one ModuleScript named `RateLimiter`, placed in `ServerScriptService/ServerModules/RateLimiter`. It must be exclusively executed by the server; do not create a LocalScript, do not put authority logic in ReplicatedStorage, and do not allow the client to provide its own limits, timestamps, counters, token balance, or block status.
Write the complete Luau ModuleScript inside a single markdown ```lua block. The code must be ready to paste into Roblox Studio, syntactically valid in Luau, and extensively commented in Portuguese. Use `game:GetService("Players")` and an appropriate monotonic time source, preferably `os.clock()`, to calculate token refill. Implement a clean and typed API, when applicable, containing at least:
1. Configuration by action/remote key, with `capacity` (maximum burst), `refillRate` (tokens per second), logging policy, and optional progressive blocking parameters.
2. `RateLimiter:Check(player, actionKey)`, returning an explicit decision and useful information, such as allowed/denied, remaining tokens, reason, and time until the next valid attempt. The state must be independent for each player + action combination.
3. A safe method to record violations and apply temporary blocking on the server, without kick or DataStore by default. The module must allow an optional audit/log callback, but never expose sensitive data to the client.
4. Full cleanup of a player's data in `Players.PlayerRemoving`, plus a simple strategy to prevent memory growth if action keys are disabled or players leave unexpectedly.
5. Protection against invalid inputs: validate whether `player` is a `Player`, whether the key exists in the configuration, and whether numeric values are finite, positive, and coherent. Configuration failures should generate useful `warn` messages on the server, without crashing the game.
6. Concurrency and reentrancy safety: explain in comments that each RemoteEvent callback is executed on the server and that the protected handler still needs to validate payload, distance, character state, permissions, price, inventory, and gameplay cooldowns. Rate limiting does not replace business rule validation.
After the ModuleScript block, include a short section called `Server integration` with separate examples, also in Lua, showing how an existing server Script should require the module and call `RateLimiter:Check(player, "ActionName")` as the first step of each RemoteEvent/RemoteFunction handler. These examples are integration snippets only: do not create a second complete system or replace existing gameplay handlers. For `RemoteFunction`, make it clear that the server must return a safe result when the limit is exceeded; for `RemoteEvent`, ignore the call and record the attempt according to the configured policy.
Do not use `RemoteEvent:FireClient` to communicate internal rate limiter details, do not use any executor code, do not depend on HTTP APIs, do not store critical state on the client, and do not implement irreversible punishments automatically. Do not trust arguments sent by the client to identify action, cost, or permission: the server Script must choose the fixed action key corresponding to the remote it is handling.
Finish with a section `How to test in Roblox Studio`, in numbered steps, explaining how to insert the ModuleScript in the correct path, how to configure the real remote names, how to test with Start Server and multiple Players, how to trigger legitimate calls and spam, how to observe Output/logs, and how to confirm that blocked requests do not execute damage, currency, purchase, or inventory changes. Respond in Brazilian Portuguese.
