Partner API Gateway: Opening a Monolith to 50+ External Partners

Overview

The client wanted to expose the backend API to external partners so the partners can build their own frontends for benefits eligibility determination and enrollment. On the surface, it sounded straightforward. In reality, it meant opening a complex monolithic backend that has the reputation of being one of the most complex and has almost 200 external systems already integrated, to potentially 20–50 more, each with their own requirements, traffic patterns, and failure modes.

The Challenge

Everyone had an opinion, and none of them were grounded in product thinking.

My leadership feared losing control of the platform. Business analysts worried about complexity spiraling. The existing system already had almost 200 external integrations, and this would add dozens more with unpredictable traffic patterns. The developers, eager to move fast, wanted to clone the existing APIs with additional parameters and let the cloud engineers figure out how to handle the load.

That last approach scared me the most. Cloning APIs would have created a maintenance nightmare: duplicated logic, and zero isolation between internal and external traffic. During Open Enrollment, when millions of users depend on the system over a short period of time, a badly behaved partner integration and having to sift through all the duplicated codes could mean a SEV1 and worse, the team on the national headline again.

The Solution

I recognized this needed product thinking before architecture. The first questions weren’t about API design or infrastructure capacity—they were: What problem are we actually solving? For whom? What’s the potential impact to our backend system and the user experience that millions of Americans depend on?

Building and Validating Hypotheses

I assembled a cross-functional team that included our engineers, business analysts, and critically—partner engineers who would actually be the consumers of the new API. We developed competing hypotheses for how to expose the backend:

Direct API cloning (the developers’ preference): Low effort, high risk. No isolation, no abstraction, adding significant technical debts.
API gateway with contract-based access: Moderate effort, clean separation of concerns, but still tightly coupled to backend deployments.
API gateway with Kafka event streaming: Higher initial effort, but fully decoupled from the monolithic backend. Partners consume events asynchronously, the backend stays isolated, and we get natural load leveling as a bonus.

We validated these against real partner needs and backend constraints. Option 3 won decisively—not because it was the most architecturally elegant, but because it was the only option that could scale to 50+ partners without putting the core system at risk.

Execution

I built the roadmap and led 6 concurrent teams through six months of delivery. This meant coordinating across partner onboarding, API contract design, event schema definition, infrastructure provisioning, security reviews, and the inevitable organizational roadblocks that come with changing how a mission-critical system operates.

Results

15 partners onboarded in the first six months
Scaled to 50+ partners by the time I left the project
Reduced peak load during Open Enrollment—the event streaming layer naturally smoothed traffic spikes that previously hammered the backend directly
Zero destabilization of the core eligibility and enrollment system throughout the rollouttly
Bonus The event streaming platform became the enabling technology that allowed us to re-write a number of heavy batch jobs to reduce the overall load on the backend system

Key Takeaway

Start with product thinking, not architecture. When everyone is debating technical approaches, step back and ask the product questions first: What’s the problem we are solving? Who are we solving it for? What’s the blast radius?

Use hypotheses to cut through complexity and politics. When you validate with real users. In this case, once we realized the partner engineers are the consumers and they have different concerns, a clearer picture emerges on what we need to consider. Architecture follows product strategy, not the other way around.