Limitations

Stellate provides Rate Limiting security for you GraphQL requests. Read what limitations Rate Limiting has in the following sections.

Availability Guarantees

Rate limiting on a global scale is not trivial. For large scale attacks (Distributed-Denial-of-Service, short DDoS) there will always be a point at which our GraphQL specific rate limiting will break. Those attacks usually do not use any of our advanced rulesets and can be mitigated by DDoS-protection offerings, like Cloudflare DDoS Protection Services

However, we do guarantee that we're not going to break your requests. Even if the rate limiting functionality is broken, we guarantee that we will "fail open" and your users won't be affected. On the other hand that means in case of problems your origin service may receive more traffic than you have configured. At most that's the amount of traffic you previously received before opting into the rate limiting feature.

Minimum/Maximum limit window

Every rule can specify their time frame for which the expenses of the requests are summed up for (rule.limit.window). The length of the window has an upper and a lower bound:

• Minimum: 1 second
• Maximum: 1 hour (3,600 seconds)
• Step size: 1 second (no fractions of a second are possible)

Region-based rate limiting

Our rate limiting solution runs per region and in the alpha version does not enforce a global rate limit yet.

Using multiple mutations in a single request

When using a RequestCount based rule for mutations, the rule will always consume either 0 or 1 points from the budget, depending on whether the rule applies to the received request. A GraphQL request is technically able to send multiple mutations. The number of mutations within a request does not influence the amount of budget points to be consumed.

If you want to restrict a request from sending multiple limits, you can find an example in our Rate Limiting Rule Examples.

Automated Persisted Queries (APQ)

Automatic Persisted Queries (APQ) are not compatible with the Rate Limiting product yet. When rate limiting is configured, any APQ request will be rejected, to disallow circumenventing your rules by using persisted queries.

If you need to have both features work together, please reach out with your use-cases!

Supported HTTP verbs

Right now only GraphQL requests sent via the POST verb are rate limited. We will expand to support GET as well shortly.

OPTIONS requests (e.g. browser preflight requests) are not forwarded to your origin (we handle them in our edge infrastructure) and thus will never consume any rate limit budget.

GraphQL Query Batching

GraphQL Query Batching is currently not compatible with the Rate Limiting product. When rate limiting is configured, any batched request will be rejected, to disallow circumenventing your rules by using batched requests.

EdgeRequest header format

HTTP headers are case-insensitive. We normalize all keys of the req.headers record to use lowercase string values only. If you use Authorization in your HTTP client, it will be available as req.headers.authorization. If you send somthing like X-My-Custom-Header it will be available as req.headers['x-my-custom-header'].