Rate Limiting and Bot Protection in Modern SaaS

June 29, 2025
Integify Team
12 min read
SecuritySoftware Development
Rate Limiting and Bot Protection in Modern SaaS

Photo by photographer on Unsplash

SaaS Rate Limiting & Bot Protection: A Survival Guide

Because nobody wants their servers crying at 3 AM

Why You Need Rate Limiting (Yesterday)

Your SaaS got popular? Congrats! Now someone's hammering your API with 50,000 requests per minute while legitimate users can't even log in. Rate limiting is your digital bouncer – it keeps the party enjoyable for everyone.

The 4 Rate Limiting Strategies That Actually Work

Fixed Window: Simple but gameable. "100 requests per hour, period."
Sliding Window: More accurate, remembers exactly when requests happened.
Token Bucket (my favorite): Users get tokens that refill over time. Allows bursts but prevents sustained abuse.
Leaky Bucket: Smooths traffic at a steady rate.
// Token bucket example
const userLimit = {
  tokens: 100,        // current tokens
  maxTokens: 100,     // bucket size
  refillRate: 1,      // tokens per minute
  lastRefill: Date.now()
}

Tiered Limits = Natural Upgrades

  • Free: 100 requests/hour (taste the product)

  • Pro: 10,000 requests/hour (serious usage)

  • Enterprise: Unlimited (they're paying for it)
  • This isn't just fair, it's product psychology. When users consistently hit limits, they are ready to upgrade.

    The Bot Situation: Good vs. Evil

    Good Bots (don't block these):
  • • Googlebot (please, for your SEO's sake)

  • • Uptime monitors

  • • Social media previews
  • Bad Bots (show them the door):
  • • Content scrapers

  • • Credential stuffers

  • • Anything making inhuman request patterns
  • Modern Bot Detection Beyond Basic Rate Limiting

    Real humans are beautifully inconsistent. They pause, mistype, move their mouse in weird patterns. Bots are eerily perfect.
    Red flags:
  • • No pauses between actions

  • • Superhuman typing speeds

  • • Perfectly straight mouse movements

  • • Always filling forms in identical order
  • Use CAPTCHAs sparingly – they work but annoy legitimate users.

    API Rate Limiting Best Practices

    When developers hit your limits, be helpful:
    {
      "error": "Rate limit exceeded",
      "message": "1001/1000 requests used this hour",
      "retry_after": 1800,
      "reset_time": "2024-01-15T15:00:00Z"
    }
    

    Distributed Systems Reality Check

    Multiple servers? Use Redis for shared rate limit counters. Plan for when Redis goes down (because it will).

    Monitor Everything

    Track normal patterns, detect anomalies, measure effectiveness. You can't manage what you don't measure.

    Handle False Positives Like a Pro

    Build escape hatches:
  • • Clear support contact

  • • Quick appeal process

  • • Regular review of flagged users

  • • Human oversight for edge cases
  • Use CDNs and WAFs

    Let Cloudflare or AWS WAF handle the obvious bad traffic before it hits your servers. Why fight battles you don't need to?

    Test Your Defenses

    Regular load testing, edge cases, failure scenarios. Run fire drills before you need them.

    The Bottom Line

    Start simple, measure everything, iterate based on real data. The goal isn't an impenetrable fortress, it's making legitimate users happy while making bad actors go bother someone else.
    Your 3 AM self will thank you for implementing this properly.
    Implementation tip: Begin with basic rate limiting, add bot detection as you scale, and always prioritize user experience over perfect security.

    Want to learn more about our services?

    Contact our team to discuss how we can help your business with digital transformation

    Get in Touch