← all work N.BANZON_JR
case 02·api gateway·vivacity app

A custom KrakenD gateway that replaced a metered vendor

The platform's integrations were fronted by a managed gateway priced against a quota. I replaced it with a custom edge built on KrakenD open source: one declarative place for routing and credentials, running on infrastructure the team already operates.

role
Backend Engineer
stack
KrakenD, NestJS, K8s
runs on
Kubernetes
year
2025 – present
01 — context

Every integration had its own front door

The platform talks to a growing set of third-party systems — property feeds, CRMs, notification services — and each of those integrations arrived with its own routing, its own auth handling, and its own place in the request path. Traffic was fronted by Azure API Management, which is priced against a quota. As integration count grew, so did the bill and the amount of gateway configuration nobody fully owned.

02 — analysis

What the gateway was actually doing

Reading the traffic first made the decision straightforward. Almost none of the managed gateway's premium surface was in use — the real work was routing, aggregating a handful of upstream calls, attaching credentials, and shaping responses. That is exactly the shape KrakenD is built for, and it runs as a container on infrastructure the team already operates.

in use
routing and path rewriting
response aggregation
credential injection
rate limiting per client
paid for, unused
developer portal
subscription tiers
managed policy engine
quota-priced throughput
03 — architecture

One declarative edge in front of the services

clients → cloudflare → krakend → services
Web app Mini Program Partner API Cloudflareedge / waf KrakenDdeclarativeendpoints search svc property svc enquiry svc 3rd party runs as a pod on kubernetes

Endpoints are declared as configuration rather than written as code, so adding an integration means describing the backend, the method, and the fields to pass through. Cloudflare stays in front for edge protection; the gateway itself is a pod in the existing Kubernetes cluster, deployed through the same Azure pipeline as every other service.

04 — outcome

Integrations got cheaper to add, and cheaper to run

01
No quota ceiling on throughput
Gateway cost became compute the team already runs, not a metered per-call charge that grows with every integration.
02
One place to read the edge
All routing lives in version-controlled configuration, reviewed in the same pull request as the service change it serves.
03
Same deploy path as everything else
Gateway changes roll out through the existing pipeline, with the same rollback and the same alerting as the services behind it.
KrakenD NestJS Kubernetes Azure DevOps Cloudflare Docker
next · case 03
Migrating search off Algolia →
case 01
Retrieve, rerank, reason →