Rate Limiting
Relevant source files
The following files were used as context for generating this wiki page:
Rate limiting is a critical infrastructure component within the GoHighLevel Clone project, designed to protect the system from abuse and ensure fair resource distribution across different accounts. It is implemented primarily as a Redis-backed mechanism that enforces request quotas on a per-account basis. Sources: README.md:36, CHANGELOG.md:46
The system specifically targets API stability by preventing any single tenant from overwhelming the backend services, which is essential for maintaining the Multi-Tenant Architecture. The default implementation imposes a limit of 100 requests per hour per account. Sources: CHANGELOG.md:47, CHANGELOG.md:50
Architecture and Implementation
The rate limiting system utilizes a distributed approach leveraging Redis to store and increment request counters. This ensures that limits are enforced consistently even when the backend is scaled horizontally across multiple instances. Sources: README.md:144, CHANGELOG.md:49
Technical Components
The implementation consists of the following key elements:
- Redis Backend: Used for distributed, atomic counter management. Sources: CHANGELOG.md:49
- Account Isolation: Limits are keyed by the
account_idderived from the authentication context. Sources: CHANGELOG.md:52 - Response Headers: The system includes rate limit metadata in API responses to inform clients of their remaining quota. Sources: CHANGELOG.md:50
The diagram above illustrates the request flow through the rate limiting middleware. Sources: CHANGELOG.md:46-52
Configuration and Limits
Rate limiting is primarily applied to the Workflows module but is designed as a cross-cutting concern for the entire API suite. Sources: CHANGELOG.md:12-14
| Parameter | Default Value | Description |
|---|---|---|
| Request Limit | 100 requests | Maximum number of allowed requests. |
| Time Window | 1 hour | The period over which requests are counted. |
| Scope | Per Account | Limits are isolated per tenant (account_id). |
| Storage | Redis | Distributed cache for counter persistence. |
Sources: CHANGELOG.md:47-50, README.md:36
Error Handling and Client Feedback
When an account exceeds its allocated quota, the system returns a standard HTTP 429 "Too Many Requests" error. This mechanism is validated through specific acceptance tests (e.g., AC-005) to ensure that the API correctly rejects subsequent requests once the threshold is met. Sources: CHANGELOG.md:51, CHANGELOG.md:103
Sequence of Rate Limit Enforcement
This sequence shows the interaction between the distributed cache and the API layer during a rate limit violation. Sources: CHANGELOG.md:46-52, backend/src/workflows/infrastructure/rate_limiter.py
Integration with TRUST 5
The rate limiting system is a core part of the "Secured" and "Trackable" pillars of the project's TRUST 5 quality framework. It ensures that the system is protected from Denial of Service (DoS) attempts at the application level and provides trackable usage metrics for each tenant. Sources: README.md:179, CHANGELOG.md:129
- Secured: Prevents resource exhaustion and protects against brute-force or runaway scripts.
- Trackable: Redis counters and audit logs provide visibility into account activity.
Summary
The rate limiting system in the GoHighLevel Clone provides a robust, Redis-backed defense mechanism. By enforcing a strict 100 request/hour limit per account, it ensures system-wide stability and prevents multi-tenant interference, directly supporting the project's commitment to enterprise-grade code quality and security. Sources: CHANGELOG.md:47-52, README.md:18