News KrakenD CE v2.8 released with improved Lua and OpenTelemetry

You are viewing a previous version of KrakenD Community Edition (v1.3), go to the latest version

Document updated on Sep 29, 2018

Throttling overview

KrakenD offers several ways to protect the usage of your infrastructure that might act at very different levels.

The most significant type of throttling is the rate limit that allows you to restrict the traffic of end-users or the traffic of KrakenD against your backend services. The rate limits mainly cover the following purposes:

  • Avoid stressing or flooding your backend services with massive requests (proxy rate limit)
  • Establish a quota of usage for your exposed API (router rate limit)
  • Create a simple QoS strategy for your API

The rate limits are complementary to the Circuit Breaker feature.

Types of rate limits

There are two different layers where the rate limiting applies:

  1. Router layer: Sets a maximum throughput to end-users hitting KrakenD endpoints.
  2. Proxy layer: Sets a maximum throughput between KrakenD and your backend services

To deep dive in the code see the rate-limiting middleware

Rate limiting a cluster

As KrakenD is a stateless API Gateway and does not have any centralization, the limits apply individually to each running instance of KrakenD. For instance, if you limit an endpoint to 100 reqs/s in the krakend.json and you have a cluster deployed with 3 instances of KrakenD, then your ecosystem is limiting to 300 reqs/s. If you add a 4th node, then you are increasing this limit to 400 reqs/s.

The Circuit Breaker

The Circuit Breaker is a state machine between the request and the response that observes the failures of the backends. When a backend seems to be failing, KrakenD ceases to send more traffic to avoid stressing the suffering backend until it is considered recovered.

The Circuit Breaker is an automatic protection measure for your stack and avoids cascade failures.

See the Circuit Breaker

Timeouts and Idle Connections

KrakenD allows you to fine-tune timeouts both for the HTTP server and the HTTP client used to access your backends. As per the IDLE connections, having a high number of them to every backend, it affects directly to the performance of the proxy layer.

Scarf

Unresolved issues?

The documentation is only a piece of the help you can get! Whether you are looking for Open Source or Enterprise support, see more support channels that can help you.

See all support channels