How Moniepoint Scaled to 102M Daily API Calls with KrakenD

Every time someone asks me how we work with KrakenD, my answer is always: I can just email the CEO directly.

The problem: one screen, too many calls

Every time a Moniepoint customer opened the banking and payments app, the mobile client fired a cascade of individual API calls to populate the home screen. Each call added latency. Each call consumed mobile data. At the scale Moniepoint operates across African markets, where connectivity is variable and data costs are real, that pattern had a direct impact on user experience.

The engineering team was running Nginx as their ingress layer. It handled traffic, but it did not solve the aggregation problem. Frontend engineers were responsible for orchestrating calls to multiple backend services, managing authentication at the client level, and absorbing the latency of every round trip. The home screen alone required coordination across several internal services before a customer saw anything.

The team needed a Backend for Frontend layer, an API gateway that could own that complexity instead of pushing it onto the mobile client. A single endpoint the app could call, one that would fan out internally to Moniepoint’s backend microservices, aggregate the responses, and return a clean payload. The question was how to build that without creating a new category of operational complexity.

Why KrakenD beat out other gateways

The evaluation was a straightforward API gateway comparison. Other gateways were assessed and ruled out quickly. The issue was not capability. It was entry cost and commercial structure.

“It’s all or nothing,” says Nicolaas Taljaard, Head of Technology Strategy and Partnership at Moniepoint. “With other gateways, you can’t start small. The pricing doesn’t allow it.”

For an R&D team running at pace, the ability to prove the technology before committing commercially mattered. KrakenD’s open-source Community Edition offered exactly that. The team deployed it, ran tests against real infrastructure, and validated the approach before any license conversation started.

“As an R&D department, we were like: cool, these guys are open source. We can try it out and deploy it even before licenses are involved.”

KrakenD was discovered at KubeCon. By the time commercial discussions began, the technical case was already closed.

What they built: two plugins, one architectural principle

Moniepoint’s KrakenD deployment is built around two custom plugins that solve distinct problems.

Mobile BFF Layer

Mobile app · single request

BFF aggregation plugin + JWT rewriter plugin

Backend service

Backend service

Backend service

One public endpoint fans out internally and returns a single aggregated response

The BFF aggregation plugin is the core of the mobile banking experience. One public endpoint receives the request from the app. The plugin fans out internally to Moniepoint’s backend microservices, aggregates the data, and returns a single response to the frontend. Frontend engineers no longer manage backend availability, authentication state, or service coordination. That complexity lives at the gateway.

The JWT rewriter plugin emerged from a scaling problem. As Moniepoint’s authorization model grew, JWT tokens became too large. The plugin takes the incoming token from the mobile client, restructures and compresses it, then calls the required backends with extended credentials attached. A compact token arrives from the client. The backend receives exactly what it needs.

Both plugins were purpose-built. Neither replaces what KrakenD does natively; they extend it to fit Moniepoint’s specific architecture.

The deployment itself runs on GCP. Development environments run on OCI. Production is entirely GCP. The Docker image carries the KrakenD configuration and license and is deployed cleanly without a separate cloud environment to manage.

The architecture evolution: from shared API gateway to per-team ownership

The original setup was a single KrakenD API gateway serving all teams, with multiple instances running the same configuration. It worked, but it created coordination overhead. A configuration change for one team required care around the entire gateway.

Before · Shared Gateway

Team A · Team B · Team C

One shared config · 40 instances

A change for one team required care around the entire gateway

After · Per-Team Ownership

Team A

KrakenD instance

Team B

KrakenD instance

Team C

KrakenD instance

25 instances, independent configs, teams ship without touching each other

The team redesigned the architecture. Each business department now runs its own KrakenD instance with its own configuration, maintained independently. Teams ship changes without touching each other. Governance is distributed by design.

The practical consequence was immediate: the team reduced from 40 production instances to 25 without a single incident. The optimization was possible precisely because each department owned its own slice and could tune independently.

The numbers

“Since we did our redesign, we’ve had zero downtime on our ingress layer for three months. Incidents have gone down. We’re currently at zero.”

The phantom cluster: finding what you didn’t know was running

Several months into production, KrakenD’s telemetry flagged an anomaly. A cluster of roughly 40 instances was reporting under Moniepoint’s license that the team had no record of. The instances were stable, long-running, and real. They just didn’t correspond to anything the team could identify in their deployment inventory.

Moniepoint’s cloud engineers searched logs across GCP and OCI. They couldn’t locate the source.

What followed was a live debugging session with KrakenD’s CEO and CTO joining Moniepoint’s cloud engineers directly in production. Together they traced the cluster fingerprint, matched it to a configuration hash, and identified the root cause: leftover plugin test instances that had been running alongside the production configuration on each VM, consuming compute resources without ever receiving public traffic.

The instances were dormant. They had no public access and had never been triggered. But they were real, they were running, and without the telemetry signal from KrakenD, they would have continued running indefinitely.

Taljaard recalls the moment:

We ended up on a call with your CEO and CTO and our cloud engineers debugging live production, looking at the instances, figuring out why there’s a duplicate, what’s going on. And we ended up finding it, thanks to them.

Once identified, the fix was straightforward. The instances were removed. The license footprint dropped to the real production baseline. No service impact. No customer-facing consequence.

The incident is a useful illustration of how KrakenD’s telemetry works in practice: it surfaces what’s happening across an entire fleet, including the parts the team has forgotten about.

Support as a relationship, not a ticket queue

Moniepoint’s support experience doesn’t follow the standard vendor pattern. Taljaard’s description of it is direct:

So that’s how open the communication is. You can actually just email the CEO, say this is the problem we have, how do we solve this, and he pulls in the right people.

The team has a paid Premium Support plan. Over the past year, they’ve rarely needed to use it formally. The KrakenD engineering team was available when it mattered, the phantom cluster investigation being the most significant example, and the day-to-day operational confidence has grown to the point where the team resolves most issues internally.

“During the last year of using KrakenD, we’ve gotten upskilled enough that we haven’t really actually needed our paid support plan.”

Before and after