Rate Limiting

Rate limiting protects KalamDB from abuse, accidental traffic spikes, and noisy clients.

This page is for operators who install and run the database in staging or production.

Why It Matters

Rate limits help you:

• Reduce brute-force pressure on authentication flows.
• Prevent one client from starving shared resources.
• Control connection floods and sudden request bursts.
• Keep user-facing performance stable during abnormal traffic.

What to Control

Tune limits in these areas:

• Query throughput per user.
• Request throughput per IP.
• Authentication attempts per IP.
• Concurrent connections per IP.
• WebSocket message and subscription pressure.
• Request body and message size caps.
• Temporary ban duration after repeated violations.

Practical Tuning Strategy

Start with conservative defaults, then adjust using real traffic data.

1. Identify normal traffic baselines (average and peak).
2. Set limits slightly above normal peaks.
3. Alert on near-limit and over-limit events.
4. Tighten limits for sensitive endpoints first.
5. Revisit thresholds after major traffic or product changes.

Environment Guidance

• Development: permissive values are acceptable, but keep protections enabled for realism.
• Staging: mirror production as closely as possible.
• Production: enforce strict limits with monitoring and clear escalation paths.

Abuse and Incident Handling

When abuse is detected:

• Increase protection on affected vectors first (auth, per-IP, or connection caps).
• Apply temporary bans with short review cycles.
• Coordinate with edge controls (WAF/CDN/ingress) for layered mitigation.
• Preserve logs for forensic analysis and policy tuning.

Common Mistakes to Avoid

• Disabling rate-limit protections in production.
• Using unlimited request body sizes.
• Setting thresholds without monitoring outcomes.
• Applying one global limit without considering endpoint sensitivity.
• Ignoring WebSocket-specific pressure controls.

Validation Checklist

• Limits are documented with owner and rationale.
• Alerts exist for violations, bans, and unusual burst patterns.
• On-call runbooks define who responds and how to tune quickly.
• Thresholds are reviewed at least quarterly.