Rate Limiting to Prevent Brute Force Attacks
Fast recall
Quick revision
Core answer
Whether the candidate can design a production-ready rate limiting strategy that considers distributed deployments, bypass techniques, and the trade-off between security and user experience.
Using only in-memory rate limiting that doesn't work across multiple instances, or applying rate limits only to login without considering other sensitive endpoints.
Discuss token bucket vs sliding window algorithms, how to handle legitimate high-traffic users, and combining rate limiting with CAPTCHA and account lockout.
Interview-ready guide
Interview answer
Why in-memory fails
- 3 instances, limit 100/min/client
- Attacker sends 100 to each -> 300/min without tripping any single counter
- Provides false security in scaled deployments
Redis-based implementation
- Bucket4j + Redis:
Bandwidth.simple(100, Duration.ofMinutes(1)) - Resilience4j RateLimiter:
limitForPeriod(100).limitRefreshPeriod(Duration.ofMinutes(1)) - Both use atomic ops; safe across instances
Brute-force protection for login
- Track failures per username in Redis with TTL
- After N failures: lock account temporarily, alert via email
- CAPTCHA after 3-5 failures — blocks bots without locking legitimate users
Key selection
- Prefer authenticated user ID or API key (stable, non-spoofable)
- IP only as fallback for unauthenticated endpoints
- For login: combine IP + username keys
Algorithms
- Token bucket (Bucket4j): allows bursts, matches real traffic
- Sliding window: precise, no boundary exploitation
- Fixed window: simplest; boundary issue acceptable for security limits
Layers
- CDN/WAF for volumetric DDoS
- API gateway for coarse limits
- Spring filter for fine-grained per-endpoint limits
- Account lockout for auth-specific protection
Rate Limiting to Prevent Brute Force Attacks
Direct Answer
Rate limiting restricts how many requests a client can make in a time window, making brute force impractical. In-memory ConcurrentHashMap rate limiting fails in clusters — every instance has its own counter, so attackers get N times the limit. Production uses Bucket4j with Redis for shared state, smart key strategy (per-IP and per-username for login), and a tiered approach: aggressive limits on sensitive endpoints (5 logins/min/IP), relaxed limits on general API (100 req/min/user), plus API gateway / WAF rate limiting at the network edge for volumetric attacks. Combine with account lockout as defense in depth.
Common Mistakes & Pitfalls
Using only in-memory rate limiting that doesn't work across multiple instances, or applying rate limits only to login without considering other sensitive endpoints.
Check your understanding
Answer these without looking back at the article.
- How would you differentiate a legitimate high-traffic API user from a bot using rate limiting?
- What is the difference between the token bucket and leaky bucket rate limiting algorithms?
- How would you prevent rate limit bypass via IP rotation or distributed attacks?
- How do you exempt internal services and health checks from rate limiting safely?
Related interview prep categories
2Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.