Implement Per-User Rate Limiting #29

New issue

Closed

opened 2026-02-13 18:34:44 +03:00 by NiXTheDev · 1 comment

NiXTheDev commented

2026-02-13 18:34:44 +03:00

(Migrated from github.com)

Add per-user rate limiting to prevent abuse and ensure fair usage of the bot.

Problem

Currently, users can send unlimited commands which could:

Overload the worker pool
Hit Telegram API rate limits
Allow abusive behavior (spam)

Solution

Implement a rate limiting system that tracks commands per user.

Implementation Details

Create RateLimiter class with configurable limits
Track requests per user ID in SQLite
Implement sliding window or token bucket algorithm
Add graceful degradation (warn users, not block completely)
Different limits for different command types

Configuration

New environment variables:

RATE_LIMIT_ENABLED - Enable rate limiting (default: true)
RATE_LIMIT_COMMANDS_PER_MINUTE - Max commands per user per minute (default: 30)
RATE_LIMIT_BURST - Allow burst of commands (default: 5)
RATE_LIMIT_WINDOW_MS - Time window for limits (default: 60000)

User Experience

When rate limit exceeded:

Send polite message: "Rate limit exceeded. Please wait X seconds."
Include remaining time in response
Log rate limit events for monitoring

Testing

Unit tests for RateLimiter
Integration tests with rapid command sending
Verify limits reset correctly

Add per-user rate limiting to prevent abuse and ensure fair usage of the bot. ## Problem Currently, users can send unlimited commands which could: - Overload the worker pool - Hit Telegram API rate limits - Allow abusive behavior (spam) ## Solution Implement a rate limiting system that tracks commands per user. ## Implementation Details 1. Create RateLimiter class with configurable limits 2. Track requests per user ID in SQLite 3. Implement sliding window or token bucket algorithm 4. Add graceful degradation (warn users, not block completely) 5. Different limits for different command types ## Configuration New environment variables: - RATE_LIMIT_ENABLED - Enable rate limiting (default: true) - RATE_LIMIT_COMMANDS_PER_MINUTE - Max commands per user per minute (default: 30) - RATE_LIMIT_BURST - Allow burst of commands (default: 5) - RATE_LIMIT_WINDOW_MS - Time window for limits (default: 60000) ## User Experience When rate limit exceeded: - Send polite message: "Rate limit exceeded. Please wait X seconds." - Include remaining time in response - Log rate limit events for monitoring ## Testing - Unit tests for RateLimiter - Integration tests with rapid command sending - Verify limits reset correctly

NiXTheDev commented

2026-02-13 18:59:56 +03:00

(Migrated from github.com)

While this is good practice, I am a bit skeptical, we already have regex time execution cap at 1min by default, and the pool self-rate-limits by having a cap on maximum workers

however, if spam does come in, the sed performance will be slowed for everyone, so, I am not against this, with normal usage this would never be an issue, plus having a safeguard is always handy

While this is good practice, I am a bit skeptical, we already have regex time execution cap at 1min by default, and the pool self-rate-limits by having a cap on maximum workers however, if spam does come in, the sed performance will be slowed for everyone, so, I am not against this, with normal usage this would never be an issue, plus having a safeguard is always handy