Rate limits, queues, and antispam for forms and bots

Rate limits, queues, and antispam are three protection layers - without them, forms and Telegram/Discord bots quickly become channels for spam, flood, and DoS. One CAPTCHA is not enough: you need frequency limits, async processing, and filters on content and reputation. Below - how to build a practical setup for sites and bots without unnecessary complexity.

• Rate limit - how many requests are allowed per time window from one IP, account, or token
• Queue - a buffer between accepting a request and heavy work (email, CRM, LLM, webhook)
• Antispam - honeypot, CAPTCHA, heuristics, blocklists, and content checks
• Rule - first cut frequency and process asynchronously, then harden filters
• Goal - keep real-user leads and keep the service up under a botnet

Why forms and bots are attacked first

A public endpoint is an unlocked door. Spam bots hunt /contact, /api/lead, and bot webhooks, then send thousands of messages: phishing, SEO spam, credential stuffing, promo-code brute force. Without limits, email/SMS/LLM bills grow, the CRM fills with junk, and real leads drown in noise.

Typical symptoms:

1. A spike in POSTs to the form with zero sales conversions
2. Identical texts from different IPs - or unique garbage from one range
3. Email or webhook queues hit provider limits
4. The messenger bot answers slower than usual or times out

Rate limiting: what to constrain and how

Rate limiting answers: "how many times in N seconds may this endpoint be hit?" The key you limit on matters.

Practical windows:

• Lead form: 3-5 successful submits per IP per 10 minutes, plus a stricter cap on failures (validation, CAPTCHA fail)
• Login / OTP: separate and stricter - otherwise brute force
• Bot commands: one heavy reply (generation, search) per user every few seconds; light commands - softer
• Global ceiling on the process or worker - protects against spikes even when keys differ

On exceed: HTTP 429 with Retry-After; in a bot - a short "wait N seconds", without revealing internal thresholds. Log hits: they show whether the limit is too soft or too hard.

Queues: why separate accept from processing

A form should not synchronously write to CRM, generate a PDF, and call an external API. A queue (Redis, RabbitMQ, SQS, Celery, BullMQ) takes the job right after validation and returns a fast response: "request accepted".

What a queue gives you:

• Peak smoothing - spam or a campaign spike does not take down web processes
• Retry on failure - backoff retries instead of lost leads
• Priorities - paid orders above "download PDF"
• Isolation - LLM/email workers scale separately from the front end

Form flow:

1. CSRF / origin check, honeypot, basic field validation
2. Rate limit
3. Persist the lead in the DB with status queued
4. Push to the queue
5. HTTP 200/202 to the user
6. Worker: antispam scoring → CRM / email / notification

Same for bots: accept the Telegram update fast; heavy replies (RAG, image, parsing) go to the queue. Otherwise long polling / webhook latency piles up.

Antispam: layers, not one checkbox

One reCAPTCHA does not close the topic. Build defense in depth.

1. Cheap filters at the edge

• Honeypot field (hidden for humans, filled by bots)
• Minimum form fill time (too fast = bot)
• Referer / Origin and CSRF token checks
• Cap request body size and attachment count

2. CAPTCHA and challenges

Show a challenge on signal, not always: after N attempts, on a suspicious IP, on a high score. Always-on CAPTCHA hurts conversion; targeted CAPTCHA almost does not.

3. Content and reputation

• Domain/URL blocklists in the message text
• Detect repeated templates and language-agnostic spam
• Email checks (MX, disposable domains)
• For bots: link filters, stop words, media limits

4. Behavioral signals

History: how many submits from this device became a purchase or a meaningful chat. A new IP with dozens of "buy seo" messages per minute goes to quarantine or manual review - not straight into a manager's CRM.

How to wire the three layers

Recommended production order:

1. Validation and cheap antispam (honeypot, size, CSRF)
2. Rate limit by IP + user/chat id
3. Fast response to the client / messenger
4. Queue with a concurrent-job cap per worker
5. Heavy antispam and integrations in the worker (scoring, CRM, email)
6. Alerts on 429 spikes and growing rejected jobs

You then avoid spending CPU and provider money on requests that should already have been cut by the limit.

Implementation checklist

• [ ] Forms and bots have different limits for different risk
• [ ] There is a global circuit breaker for outbound email/SMS/LLM
• [ ] 429 and bot messages are clear to humans but do not hint how to bypass
• [ ] The queue has a DLQ (dead letter) and length monitoring
• [ ] Suspicious leads go to quarantine, not silent delete
• [ ] Rate-limit and spam-score logs are usable without full PII access
• [ ] Load test: what happens at 100 RPS on /contact

Bottom line

A rate limit cuts frequency, a queue protects the backend and integration budgets, antispam separates junk from leads. They only work together: a limit without a queue still knocks down synchronous handlers; a queue without filters spreads spam across the CRM; filters without a limit get expensive under DDoS.

If you need form and bot protection designed for your stack (limits, queue, quarantine, monitoring) - contact me. Support and enhancement guides - on the pricing page.

Frequently asked questions

How is a rate limit different from antispam?

A rate limit counts attempts; antispam judges content and behavior. A limit stops flood even from "clean" requests; antispam catches rare but toxic spam that still fits inside the limit.

Do I need a queue if lead volume is low?

Yes, if you call external APIs, email, or an LLM. Even with low traffic, a synchronous CRM timeout breaks form UX. A queue is cheap at idle and saves you in a spike.

Is CAPTCHA mandatory on every form?

No. Prefer challenges by risk: after error bursts, from bad IP reputation, or on an anomalous score. You annoy fewer people and still cut bots.

In a bot, limit by chat_id or by IP?

Both. chat_id stops one-user flood; IP/webhook token protects against forged updates and scanning. Group limits are usually stricter than DMs.

What should I do with leads that look like spam?

Put them in quarantine for manual review or delayed delivery - not in the trash with no trace. Otherwise you lose a rare real lead and never see how attack patterns evolve.

Terms in this article

webhooks — HTTP callbacks when events happen

LLM — Large Language Model

CRM — Customer Relationship Management

PII — Personally Identifiable Information

DDoS — Distributed Denial of Service