Changing component execution order with KrakenD Workflows

Components of the API Gateway play a crucial role in validating, proxying, transforming, and securing requests and responses. We call these components the “middleware ,” which execute in a predefined order. For instance, you validate a JWT token first, then transform the request later, not vice versa. You can find here the component execution order.

However, there will be times when guaranteeing an execution order is vital for your logic. KrakenD Workflows provide an elegant way to define the sequence in which internal middleware should execute. Let’s explore workflows!

Understanding KrakenD Workflows

KrakenD Workflows allow you to nest a KrakenD flow inside another KrakenD flow (an execution pipe), creating a structured execution flow for internal processing.

Instead of applying all middlewares in a single pipeline, Workflows enable you to split processing into sub-pipes, where different middleware logic can be applied at different stages. This makes it possible to control execution order explicitly by deciding which middlewares run in which sub-workflows.

For example, you can first process authentication in one pipe, apply rate limiting in another, and then transform responses in a final pipe. This modular approach helps organize middleware execution while improving maintainability and readability.

When to Use Workflows

You should use Workflows when:

• You need a specific execution order for multiple middlewares.
• You want to group related middlewares into structured processing stages.
• You need granular control over the processing of requests and responses.

Defining a Workflow in KrakenD

A simple example of using Workflows is changing the execution order of rate limiting and circuit breaking.

By default, KrakenD executes the circuit breaker before the rate limiter. However, you may want to invert this order, ensuring that rate limiting happens first and circuit breaking is only applied if the request is within allowed limits.

To achieve this, you need to:

• Enable the rate limiter outside the workflow (so it executes first).
• Place the circuit breaker inside the workflow (so it runs after the rate limiter).

Blocking excessive requests upfront can prevent unnecessary circuit breaker trips with this example. Let’s examine how to set up a Workflow in KrakenD’s configuration.

Defining the Rate Limit

Create a simple KrakenD configuration with a rate limiter, limiting the load to 50 request per second. Here’s a simple example:

{
  "version": 3,
  "port": 8080,
  "endpoints": [
    {
      "endpoint": "/"
      "backend": [
        {
          "url_pattern": "/__debug/",
          "host": ["localhost:8080"],
          "extra_config": {
            "qos/ratelimit/proxy": {
              "max_rate": 50,
              "capacity": 50
            }
          }
        }
      ]
    }
  ]
}

Add a workflow to the newly defined backend

In order to add a workflow to the backend with the circuit breaker inside, there are some changes required:

{
  "version": 3,
  "port": 8080,
  "endpoints": [
    {
      "endpoint": "/"
      "backend": [
        {
          "url_pattern": "/__debug/",
          "host": ["localhost:8080"],
          "extra_config": {
            "qos/ratelimit/proxy": {
              "max_rate": 50,
              "capacity": 50
            },
            "workflow": {
              "endpoint": "/workflow1",
              "backend": [
                {
                  "url_pattern": "/__debug/",
                  "host": ["localhost:8080"],
                  "extra_config": {
                    "qos/circuit-breaker": {
                      "interval": 60,
                      "timeout": 10,
                      "max_errors": 1,
                      "name": "cb-myendpoint-1",
                      "log_status_change": true
                    }
                  }
                }
              ]
            }
          }
        }
      ]
    }
  ]
}

With this configuration:

1. Rate limiter runs first (since it is outside the workflow).
2. Circuit breaker runs next (as part of the workflow).

This is a simple example, but it demonstrates how you could define an arbitrary order of execution of the internal middleware for a given endpoint.

Key Benefits of Workflows

• Predictability – You explicitly define the execution order, avoiding unexpected behavior.
• Modular Processing – Organize middlewares into structured sub-pipes.
• Flexibility – Easily modify workflows without changing every individual endpoint.

Final Thoughts

KrakenD Workflows efficiently nest pipes inside other pipes, enabling structured middleware execution. Whether you need to enforce security, optimize performance, or structure complex processing pipelines, Workflows offers a powerful and flexible solution.

If you’re building APIs with KrakenD and haven’t explored Workflows yet, now is the time to start!

Have any questions or use cases? Get in touch!