It’s extendable. That’s the most crucial part for us. We write Go for all of our services, so KrakenD was the native choice. Once you set it up, it’s good to go. We have had no gateway-related production incidents in the period we have been running it.
The API Gateway as Paribu’s Product Boundary
Paribu is Turkey’s leading cryptocurrency exchange. For an exchange, the API gateway is not an infrastructure component. It is the product boundary. Every order placed, every cancellation processed, and every market-data query answered passes through it, and crypto traffic does not arrive evenly: a market move can multiply order flow within seconds, and the gateway has to absorb that peak without becoming the constraint on the trading path.
When the platform team started planning a full infrastructure overhaul in late 2025, the gateway question was central. The team ran a structured evaluation of the available options against Paribu’s regulatory and operational requirements: configuration as code, auditability, extensibility, and the ability to run the gateway on Paribu’s own infrastructure. A custom-built gateway was prototyped first and proved the concept, but made the long-term cost obvious. Maintaining it in production, extending it for compliance requirements, and keeping it alive as traffic grew would consume engineering capacity that had better uses.
KrakenD was selected at the end of that evaluation. Hayati İbiş, the Staff Software Engineer leading the project, started with an MVP on the Community Edition to validate the routing and authentication model. Once it held up, the team moved to Enterprise.
Configuration as Code Was Not Negotiable
Paribu operates under Turkish financial regulatory requirements. The gateway’s behaviour must be auditable, deterministic, and version-controlled, and every change to it must leave a reviewable trail.
Those constraints ruled out any gateway that lives primarily in a UI. A UI-based system produces no audit trail, no diff history, and no way to enforce review gates before a configuration change reaches production. The engineering team’s position on this was clear: configuration as code is not a preference, it is a requirement.
KrakenD’s declarative model fit that requirement exactly. Every configuration change is a commit. Every commit has an author, a timestamp, and a reviewable diff. The CI/CD pipeline that deploys the gateway is the same pipeline that deploys everything else.
The gateway runs on Paribu’s own infrastructure, operated by Paribu’s own engineers. The configuration lives in Paribu’s repository, the build and deployment run on Paribu’s pipeline, and access control, audit logging, and the in-house plugins are Paribu’s. KrakenD supplies the software under licence; it does not operate any part of the gateway and holds no access to it. Responsibility for the gateway, and for everything that passes through it, sits with Paribu.
Anıl Küçükrecep, Head of Technology at Paribu, explains the thinking behind that ownership model:
We didn’t want the platform team to become a bottleneck. The goal was to centralize the guardrails, not the ownership. Teams should be able to move independently, while the platform makes sure every change follows the same standards.
Three Phases From First Commit to Production
First commit: November 25, 2025. Production go-live: April 8, 2026. Total: four and a half months. The build happened in three distinct phases, each with a specific goal.
Phase 1, Community Edition MVP, roughly 8 weeks. One endpoint template. One goal: prove that the routing and authentication model works. KrakenD’s JWT/OIDC validation against Paribu’s identity provider was the critical test. The MVP held.
Phase 2, Enterprise and Flexible Configuration, roughly 11 weeks. As endpoint types multiplied, REST, WebSocket, gRPC, conditional backends, and mock, it became clear that a single monolithic configuration file would not scale to 500+ routes across 15+ teams. The team adopted KrakenD’s Flexible Configuration and built a custom template layer on top of it.
The design principle: any backend engineer should be able to add their own endpoint without knowing how KrakenD works. They only need their endpoint’s backend URL, HTTP method, and any headers to whitelist. The template system handles the rest.
Hayati İbiş puts the real challenge this way:
The hard part wasn’t getting routes into KrakenD. It was designing a system where hundreds of routes could be owned by different teams without losing consistency. Templates, partials, and pre-checks gave us that balance.
By go-live, the repository had 635 commits from engineers across the entire backend organisation, not from the platform team alone. Every one of them merged through the same review and pre-check pipeline that governs the gateway today.
Phase 3, partials, pre-checks, and operational hardening. The team extended the Flexible Configuration with partials that encode shared behaviours, so that each route gets the same policies without each team re-implementing them. A multi-stage Docker container build guarantees that the compiled KrakenD configuration is always valid before it reaches production. Pre-checks run automatically on every pull request.
From Request to Reviewed Pull Request in Minutes
During the build, Anıl Küçükrecep built an internal agent on top of the template system. A backend engineer describes the endpoint they need, backend URL, HTTP method, any rate limit or circuit breaker preferences, and the agent drafts a pull request against the gateway repository. Pre-checks run automatically. If the configuration compiles, the PR is ready for human review.
What takes minutes is getting from a request to an open pull request that has passed the pre-checks. Nothing reaches production on that path alone: every pull request requires approval from the owning team’s CODEOWNER before it can be merged, and the pre-checks are a gate in front of that review, not a substitute for it. What the agent removes is the drafting work, not the control. The backend engineer does not need to understand KrakenD’s configuration syntax, and the platform team does not need to author the change. The entire change, author, reviewer, approval, and merge, is tracked in Git with full authorship, which satisfies the audit requirements that shaped the architecture from the start.
The Architecture in Production
Services
Services
Services
Operated on Paribu's own infrastructure, on a small fixed compute footprint
Operated on Paribu's own infrastructure, on a small fixed compute footprintEvery backend team owns its endpoint JSONs through CODEOWNERS. A pull request triggers a CI pre-check and must then be approved by a CODEOWNER before it can merge into the templates and partials that the platform team maintains. The multi-stage Docker build compiles the final configuration and guarantees it is valid before it ever reaches KrakenD Enterprise, which now handles 500+ routes across the endpoint types Paribu runs: REST, WebSocket, gRPC, conditional, and mock.
Performance in Production
Paribu’s production telemetry shows that the gateway is not where request time is spent. KrakenD’s own contribution to end-to-end latency on the order path is a small fraction of the total and is not the bottleneck. That holds during market-driven peaks, when order flow multiplies within seconds: the gateway’s share of request time does not move, and the team has not had to scale the gateway to follow those peaks. It runs on a small, fixed compute footprint, and that footprint has stayed fixed as traffic grew.
Extending the API Gateway in Go
Paribu writes its services in Go, and extending KrakenD followed the same language. Two in-house plugins run in production, one for API key management and one for compliance logging. Both are maintained by the platform team and integrated through the same CI pipeline that validates the gateway configuration, so a plugin change is reviewed and released exactly like a route change. The first working version of the API key plugin took days, not months; production-grade took weeks.
The Stack in Production
Beyond the two plugins, Paribu runs the following KrakenD Enterprise features:
- JWT/OIDC validation against Paribu’s identity provider
- Flexible Configuration with templates and partials
- Circuit breaker and rate limiting
- OpenTelemetry for observability
- REST, gRPC, WebSocket, and conditional backends
- Automatic Postman collection and OpenAPI spec generation from rendered configuration
Paribu’s API Gateway Today
| Today | |
|---|---|
| Gateway solution | KrakenD Enterprise, self-hosted and operated by Paribu |
| Configuration model | Configuration as code: templates + partials, every change a reviewed commit |
| Teams contributing to the gateway repo | 15+ backend teams |
| Routes in production | 500+ across REST, WebSocket, gRPC, conditional, and mock |
| Time to an open, pre-checked pull request | Minutes, via the internal agent; merge requires CODEOWNER approval |
| Traffic profile | Sustained high-volume order and market-data traffic with sharp, market-driven peaks; the gateway is not the bottleneck at peak |
| Extensions | Two in-house Go plugins, shipped through the same CI pipeline |
The self-service model that Hayati İbiş built, templates, partials, the internal agent, and pre-checks, is the standard way Paribu’s engineering organisation ships API endpoints today. The platform team owns the gateway and the guardrails around it, and the 15+ backend teams author the routes they run within those guardrails. Accountability for the gateway remains with the platform team. In the period Paribu has been running KrakenD in production, there have been no gateway-related production incidents.
Ready to simplify your API management?
See how KrakenD can help your team achieve similar results.
