The problem that triggered the migration
UltraGroup’s architecture needed to answer one question cleanly: when a user arrives, are they paying in cash or spending loyalty points? That single distinction determines pricing strategy, which backend namespace handles the request, and what gets rendered on the frontend.
With over 60 million unique users coming in through different banking partners and loyalty programs, each with their own business model, the answer couldn’t live in the backend. It had to live at the API layer. Their previous gateway couldn’t do it. KrakenD’s dynamic routing through JWT claims could.
The team already knew the product. Andrés Ayala and Santiago Patiño had been working with the Community Edition for over a year before making the Enterprise decision. Dynamic JWT routing tipped the balance, but it wasn’t the only reason. Running a platform that handles millions of users across more than 20 countries demanded enterprise-grade backing: an SLA, direct access to the engineers behind the product, and the certainty that production issues would be answered by people who built the gateway, not a generic support queue. Once those pieces were on the table, the conversation was over.
Configuration as code: an engineering standard, not a convenience
One of the less obvious but deeply-felt advantages of KrakenD at UltraGroup is the declarative configuration model. Andrés put it directly:
Working in a UI feels amateur, like a junior. You get used to three clicks on screen, but then there’s no trace of who did what. A commit tells you everything: who has access, what changed, when. Having an API Gateway with configuration as code, in a declarative instance, is a pillar of our architecture.
For a team managing hundreds of APIs across multiple tenants and deployment environments, auditability isn’t optional. A JSON or YAML file in version control gives UltraGroup what no UI-based gateway can: a full history, reviewable changes, and a CI/CD pipeline that deploys the gateway the same way it deploys everything else.
JWT claims as the differentiation engine
The travel product search flow is where the architecture pays off most visibly. A user searching for flights sees different pricing, different availability, and different payment options depending on whether they are a cash customer or a loyalty program member. Before KrakenD, that differentiation lived in the backend, duplicated across services, rebuilt every time a new partner or product variant was added.
With KrakenD, the JWT token the user carries already contains the context: business model, marketplace, payment mode. KrakenD reads those claims and routes the request to the appropriate Kubernetes namespace. No backend involvement. No code changes per variant. The same endpoint serves all models.
A single API layer capable of serving multiple products and marketplaces. Dynamic adaptation with no code changes.
Time-to-market for new product variants dropped from months to weeks. Building the equivalent routing logic internally, the team estimated, would have taken at least 6 months in their .NET stack, producing a system only they could maintain. As Andrés put it: “Zapatero a tus zapatos. We don’t build API gateways. We build the applications that create value for the business.”
What changed in practice
| Before KrakenD | With KrakenD | |
|---|---|---|
| Time to launch a new product variant | 3 to 5 months | Weeks |
| Orchestration logic | Distributed across multiple services | Centralized in declarative configuration |
| Integration microservices | Required per variant | Eliminated |
| Initial development effort | Baseline | 60–70% reduction |
| New market or tenant | Full development cycle | Configuration change |
The reduction in effort is not just an engineering metric. Every month saved in a launch cycle is a month of commercial advantage in a sector where speed of distribution matters.
Where the architecture is headed
UltraGroup is currently completing its migration, with the infrastructure and platform team managing KrakenD manifests centrally. The next phase moves toward federated governance: individual teams will own their configuration templates, with CI/CD handling the assembly and deployment of the combined manifest.
KrakenD’s Flexible Configuration makes this possible without losing control. Sensitive internal APIs can stay isolated in their own configuration partitions without being exposed to teams that don’t need them, even when everything ends up deployed through the same pipeline.
The team also applies a practical grouping principle to instance management: stable APIs that change infrequently are kept separate from high-churn endpoints. That way, the services that need daily deploys don’t force unnecessary rollouts on the ones that don’t.
The result
KrakenD is now a strategic component of UltraGroup’s architecture. When a new product variant is scoped, the question is no longer what services need to be built. It is how the gateway configuration needs to change.
The documentation quality, the clarity of versioning across releases, and the ease of finding the right answer quickly have all contributed to an adoption curve that required no formal certification path. The team learned by doing, chapter by chapter, exactly when each piece of knowledge was needed.
Ready to simplify your API management?
See how KrakenD can help your team achieve similar results.






