Context.
We worked with a large enterprise gaming and sports betting platform generating more than $1B in annual revenue and processing millions of transactions per day. The operator wanted to onboard third-party suppliers that would use the platform’s services while continuing to manage their own users and transactions.
The platform services operated from Dublin, while suppliers were based across Australia and New Zealand, creating approximately 170 ms of baseline network latency between the two regions. The first supplier alone was expected to introduce around 1,000 requests per second at peak, with additional suppliers already in the pipeline.
Supplier onboarding had therefore become a commercial scaling constraint. Every new integration introduced more traffic, engineering coordination, and operational risk into the same transaction path used by the operator’s internal products.
The core challenge was that more than 15 internal services relied on proprietary Java protocols with no REST APIs, while all supplier traffic was routed through a single central transaction system.
🟦 Blue: Internal platform traffic 🟨 Yellow: Supplier traffic
We worked with a large enterprise gaming and sports betting platform generating more than $1B in annual revenue and processing millions of transactions per day. The operator wanted to onboard third-party suppliers that would use the platform’s services while continuing to manage their own users and transactions.
The platform services operated from Dublin, while suppliers were based across Australia and New Zealand, creating approximately 170 ms of baseline network latency between the two regions. The first supplier alone was expected to introduce around 1,000 requests per second at peak, with additional suppliers already in the pipeline.
Supplier onboarding had therefore become a commercial scaling constraint. Every new integration introduced more traffic, engineering coordination, and operational risk into the same transaction path used by the operator’s internal products.
The core challenge was that more than 15 internal services relied on proprietary Java protocols with no REST APIs, while all supplier traffic was routed through a single central transaction system.
🟦 Blue: Internal platform traffic 🟨 Yellow: Supplier traffic
Problem Statement.
Shared infrastructure contention: The first supplier alone introduced approximately 1,000 requests per second into an already heavily used transaction system. Each additional supplier increased contention on the platform’s primary revenue path.
Shared infrastructure contention: The first supplier alone introduced approximately 1,000 requests per second into an already heavily used transaction system. Each additional supplier increased contention on the platform’s primary revenue path.
Shared infrastructure contention: The first supplier alone introduced approximately 1,000 requests per second into an already heavily used transaction system. Each additional supplier increased contention on the platform’s primary revenue path.
High cross-region latency: Supplier traffic crossed two intermediate systems on a Dublin-to-ANZ path with approximately 170 ms of baseline latency. In gaming and betting, avoidable delay can affect transaction completion and the end-user experience.
High cross-region latency: Supplier traffic crossed two intermediate systems on a Dublin-to-ANZ path with approximately 170 ms of baseline latency. In gaming and betting, avoidable delay can affect transaction completion and the end-user experience.
High cross-region latency: Supplier traffic crossed two intermediate systems on a Dublin-to-ANZ path with approximately 170 ms of baseline latency. In gaming and betting, avoidable delay can affect transaction completion and the end-user experience.
N × M integration complexity: Each of N suppliers needed access to more than 15 internal services. Without a unified API surface, this created an N × 15+ point-to-point integration model, with custom code required for every connection. Retrofitting REST APIs across the estate would have required a multi-team, multi-quarter programme.
N × M integration complexity: Each of N suppliers needed access to more than 15 internal services. Without a unified API surface, this created an N × 15+ point-to-point integration model, with custom code required for every connection. Retrofitting REST APIs across the estate would have required a multi-team, multi-quarter programme.
N × M integration complexity: Each of N suppliers needed access to more than 15 internal services. Without a unified API surface, this created an N × 15+ point-to-point integration model, with custom code required for every connection. Retrofitting REST APIs across the estate would have required a multi-team, multi-quarter programme.
No centralised operational view: Third-party outages were often discovered only after end-user complaints. Each service managed its own health checks, with no aggregated view of supplier and platform health.
No centralised operational view: Third-party outages were often discovered only after end-user complaints. Each service managed its own health checks, with no aggregated view of supplier and platform health.
No centralised operational view: Third-party outages were often discovered only after end-user complaints. Each service managed its own health checks, with no aggregated view of supplier and platform health.
Brittle supplier onboarding: Every new supplier required custom integration work across multiple legacy Java services. A single operation could span two or three files with three levels of indirection, and no standardised API contracts existed.
Brittle supplier onboarding: Every new supplier required custom integration work across multiple legacy Java services. A single operation could span two or three files with three levels of indirection, and no standardised API contracts existed.
Brittle supplier onboarding: Every new supplier required custom integration work across multiple legacy Java services. A single operation could span two or three files with three levels of indirection, and no standardised API contracts existed.
Outcome/Impact.
15+
15+
15+
Legacy services abstracted
Legacy services abstracted
Legacy services abstracted
2 hops
2 hops
2 hops
Eliminated from critical path
Eliminated from critical path
Eliminated from critical path
1k req/s
1k req/s
1k req/s
Per-vendors peak load supported
Per-vendors peak load supported
Per-vendors peak load supported
Lower transaction latency: Removed two intermediate systems from the supplier transaction path. Calls now flow through the gateway directly to the required supplier or internal services, bypassing the most contended infrastructure.
Lower transaction latency: Removed two intermediate systems from the supplier transaction path. Calls now flow through the gateway directly to the required supplier or internal services, bypassing the most contended infrastructure.
Lower transaction latency: Removed two intermediate systems from the supplier transaction path. Calls now flow through the gateway directly to the required supplier or internal services, bypassing the most contended infrastructure.
Lower transaction latency: Removed two intermediate systems from the supplier transaction path. Calls now flow through the gateway directly to the required supplier or internal services, bypassing the most contended infrastructure.
Faster supplier onboarding: New suppliers are onboarded through configuration files instead of custom integration code. Standardised OpenAPI contracts provide a consistent interface across all integration points.
Faster supplier onboarding: New suppliers are onboarded through configuration files instead of custom integration code. Standardised OpenAPI contracts provide a consistent interface across all integration points.
Faster supplier onboarding: New suppliers are onboarded through configuration files instead of custom integration code. Standardised OpenAPI contracts provide a consistent interface across all integration points.
Faster supplier onboarding: New suppliers are onboarded through configuration files instead of custom integration code. Standardised OpenAPI contracts provide a consistent interface across all integration points.
Reduced time to market: Supplier go-live moved from months of custom engineering work to days of configuration, with a path to hours through automated onboarding pipelines.
Reduced time to market: Supplier go-live moved from months of custom engineering work to days of configuration, with a path to hours through automated onboarding pipelines.
Reduced time to market: Supplier go-live moved from months of custom engineering work to days of configuration, with a path to hours through automated onboarding pipelines.
Reduced time to market: Supplier go-live moved from months of custom engineering work to days of configuration, with a path to hours through automated onboarding pipelines.
Centralised operational visibility: Recursive dependency checks and Datadog synthetic monitors provide real-time visibility into supplier and internal service health.
Centralised operational visibility: Recursive dependency checks and Datadog synthetic monitors provide real-time visibility into supplier and internal service health.
Centralised operational visibility: Recursive dependency checks and Datadog synthetic monitors provide real-time visibility into supplier and internal service health.
Centralised operational visibility: Recursive dependency checks and Datadog synthetic monitors provide real-time visibility into supplier and internal service health.
Lower implementation complexity: Complex orchestration, including more than 30 concurrent fan-out calls and response merging, was implemented through compact Lua plugins instead of distributed Java handler hierarchies.
Lower implementation complexity: Complex orchestration, including more than 30 concurrent fan-out calls and response merging, was implemented through compact Lua plugins instead of distributed Java handler hierarchies.
Lower implementation complexity: Complex orchestration, including more than 30 concurrent fan-out calls and response merging, was implemented through compact Lua plugins instead of distributed Java handler hierarchies.
Lower implementation complexity: Complex orchestration, including more than 30 concurrent fan-out calls and response merging, was implemented through compact Lua plugins instead of distributed Java handler hierarchies.
Reusable platform capability: Other product teams began adopting the gateway pattern for their own integration boundaries.
Reusable platform capability: Other product teams began adopting the gateway pattern for their own integration boundaries.
Reusable platform capability: Other product teams began adopting the gateway pattern for their own integration boundaries.
Reusable platform capability: Other product teams began adopting the gateway pattern for their own integration boundaries.
Solution.
We introduced Kong as a unified API gateway at the integration boundary. Built on Nginx and LuaJIT, Kong provided the performance required for a latency-sensitive transaction path and the extensibility needed for supplier-specific routing, authentication, and request orchestration.
🟦 Blue: Internal traffic (unchanged, still uses Central Transaction System)
🟨 Yellow: vendors traffic (now routed through Kong, bypassing intermediaries)
🟩 Green: Kong API Gateway (new boundary layer
Supplier traffic no longer flows through the central transaction system or its intermediaries. The gateway routes requests directly to the required supplier systems and internal services, while internal products continue to use the existing central path without the additional supplier load.
We chose Kong’s plugin chain model because it maps cleanly to the layered concerns of multi-supplier integration:
Global plugins (Datadog, correlation IDs, structured logging): Every request receives consistent observability without requiring per-service instrumentation.
Service plugins (authentication, supplier identification): A custom plugin loads supplier-specific configuration into the request context during authentication. Downstream processing uses this context without repeated lookups.
Route plugins (per-API handlers): Each API endpoint has its own handler for orchestrating calls to the required internal services. New routes can be added without modifying existing ones.
Supplier onboarding is configuration-driven. Each supplier is defined through a JSON configuration file containing endpoints, credentials, and metadata. Adding a new supplier now means adding configuration, not writing integration code across multiple Java services.
The gateway was deployed on AWS EKS across two regions: ap-southeast-1 for supplier proximity in ANZ and eu-west-1 for access to internal services in Dublin.
The operator created a repeatable supplier integration boundary without rewriting more than 15 legacy services. New suppliers can launch faster, external traffic is isolated from the core transaction path, and operational teams gain a consistent view of supplier health. The gateway now provides a scalable foundation for future supplier, vendor, and regional expansion.
Road Ahead.
Vendor-facing gateway: The same pattern can replace the legacy integration service on the external vendor side, moving from per-vendor Java handlers to Kong plugins with standardised health checks and observability.
Cross-team adoption: Other product teams have started evaluating Kong for their own integration boundaries, using this implementation as a reference architecture.
Runtime-configurable processing chains: The plugin model can support region-specific regulatory and compliance requirements through configurable processing chains, without introducing branching across the application codebase.
Tech stack used.
We introduced Kong as a unified API gateway at the integration boundary. Built on Nginx and LuaJIT, Kong provided the performance required for a latency-sensitive transaction path and the extensibility needed for supplier-specific routing, authentication, and request orchestration.
🟦 Blue: Internal traffic (unchanged, still uses Central Transaction System)
🟨 Yellow: vendors traffic (now routed through Kong, bypassing intermediaries)
🟩 Green: Kong API Gateway (new boundary layer
Supplier traffic no longer flows through the central transaction system or its intermediaries. The gateway routes requests directly to the required supplier systems and internal services, while internal products continue to use the existing central path without the additional supplier load.
We chose Kong’s plugin chain model because it maps cleanly to the layered concerns of multi-supplier integration:
Global plugins (Datadog, correlation IDs, structured logging): Every request receives consistent observability without requiring per-service instrumentation.
Service plugins (authentication, supplier identification): A custom plugin loads supplier-specific configuration into the request context during authentication. Downstream processing uses this context without repeated lookups.
Route plugins (per-API handlers): Each API endpoint has its own handler for orchestrating calls to the required internal services. New routes can be added without modifying existing ones.
Supplier onboarding is configuration-driven. Each supplier is defined through a JSON configuration file containing endpoints, credentials, and metadata. Adding a new supplier now means adding configuration, not writing integration code across multiple Java services.
The gateway was deployed on AWS EKS across two regions: ap-southeast-1 for supplier proximity in ANZ and eu-west-1 for access to internal services in Dublin.
The operator created a repeatable supplier integration boundary without rewriting more than 15 legacy services. New suppliers can launch faster, external traffic is isolated from the core transaction path, and operational teams gain a consistent view of supplier health. The gateway now provides a scalable foundation for future supplier, vendor, and regional expansion.
Road Ahead.
Vendor-facing gateway: The same pattern can replace the legacy integration service on the external vendor side, moving from per-vendor Java handlers to Kong plugins with standardised health checks and observability.
Cross-team adoption: Other product teams have started evaluating Kong for their own integration boundaries, using this implementation as a reference architecture.
Runtime-configurable processing chains: The plugin model can support region-specific regulatory and compliance requirements through configurable processing chains, without introducing branching across the application codebase.
