Extract Services. Not Chaos.

No. KrakenD does not refactor your codebase, extract your services, or decide which parts to break apart. If the question is whether you should break up your monolith, KrakenD does not answer it. What KrakenD answers is what happens once you have more than one backend: how you manage what sits between them and the clients that call them. Whether that is one extracted service alongside a monolith, or 3,500 microservices serving a Super App, the layer is the same.

No. The composition layer KrakenD provides is useful any time you have more than one backend serving the same client. Whether you are mid-migration, post-migration, or pre-migration and still on a monolith but planning ahead, the cross-cutting concerns problem is the same.

It eliminates the hardest constraint of incremental migration: the moment when a single client request needs data from both the monolith and a newly extracted service. A reverse proxy cannot serve both in one response without breaking the client contract. KrakenD calls both backends in parallel and stitches the results into a single response. You extract services at your own pace without coordination pain.

Yes. KrakenD routes traffic by path prefix. You point new paths to extracted services and legacy paths to the monolith. For endpoints that need data from both, KrakenD composes the response. The client calls the same endpoint throughout. When the monolith is retired, only the routing config changes.

They move to KrakenD on day one, before any service is extracted. JWT validation, rate limiting, caching, and observability stop living in individual backends and start living in the gateway. Each extracted service inherits those controls automatically, with no additional implementation required.

Yes. lastminute.com runs this model across 50 teams. Each team manages its own gateway config as part of its normal development cycle. Config is declarative JSON, versioned in Git, deployed through CI/CD. Adevinta went further: any developer on the team can manage gateway configuration, not just infrastructure specialists.

A reverse proxy routes one request to one backend. KrakenD composes: it can call multiple backends simultaneously, merge their responses, filter fields, and return a single coherent object to the client. During a monolith-to-microservices migration, this is the difference between extracting services without breaking clients and having to coordinate API contract changes with every consumer before you can move.

Yes. KrakenD handles SOAP transformation natively in declarative config. If your monolith exposes SOAP services and you want to expose them as REST to modern clients, that transformation lives in the gateway. No backend changes required.

Yes, because the gateway question is independent of the migration decision. Whether you decide to stay on the monolith, extract some services, or go fully distributed, the cross-cutting concerns layer has the same value. Understanding what that layer looks like before you start extracting services is what makes the strangler fig pattern safe in practice.