When One Dashboard Isn't Enough: An Interview with Khushan Adatiya

Most large enterprises cannot answer a basic question about their own infrastructure: how many APIs do they actually have. 78% of enterprise decision-makers admit they don't know how many APIs are running in their environment, and a separate survey found that 74% consider a significant share of those APIs unmanaged. The operational consequence is not theoretical. Fragmented visibility across gateway environments means incidents take longer to isolate, compliance gaps go undetected, and teams migrating between platforms have no reliable picture of the estate they are inheriting. The discipline of API governance has matured, but the infrastructure for putting it into practice at scale is still catching up.

Khushan Adatiya is a Senior Software Engineer with over a decade of experience building distributed systems at scale, spanning cloud infrastructure, API governance, and security. He led the design and delivery of API Insights within Google's API Hub platform, the first system to unify runtime analytics across all Apigee gateway deployment models in a single management interface. He is also the author of the published analysis "Scalability With AI: Lessons From Real Production Systems", which examines how production AI systems fail at scale and what engineering teams can do before the failure arrives.

We spoke with Adatiya about what it actually takes to give enterprises a unified view of their API landscape, and why that problem is harder than it sounds.

Large enterprises have been managing APIs for over a decade. Why is visibility still this hard to get right?

The visibility problem is not primarily technical. It is organizational. APIs get created by different teams, on different timelines, using whatever gateway or deployment model that team was already running. Some are on modern managed infrastructure. Some are on hybrid deployments. Some are on systems that have been running since before the cloud strategy was written. Over time, you accumulate an estate where no single person or team has the complete picture, because no single system was ever designed to provide it.

What makes it persistently hard is that proliferation happens faster than governance. A team ships a new integration, and by the time those endpoints are catalogued, new ones are already in flight. The management layer is always a sprint behind. You cannot govern what you cannot see, and in most large organizations the gap between what is deployed and what is tracked is larger than anyone wants to admit.

Your work on API Insights was specifically about building unified analytics across deployment models that were never designed to share data. What did that actually require?

It required treating each gateway type as a distinct data source with its own ingestion path, rather than assuming a common format and trying to normalize on the way in. Apigee X, Hybrid, Edge, and the on-premise deployment each produce runtime data differently. The ingestion architecture had to be adapted for each, and then the correlation logic had to reliably map that data back to the right API, version, and deployment entity inside the hub. That mapping sounds straightforward until you encounter cases where metadata is incomplete or where the same API exists in multiple environments at different versions. Getting that right under production conditions is the engineering problem, not the pipeline itself. The motivation is clear enough. 57% of organizations suffered an API-related data breach in the past two years, with the majority of incidents tracing back to endpoints that were either unmonitored or managed outside formal governance structures.

We also built the data pipeline to handle customers running multiple gateway types simultaneously, which is the common case in large enterprises. A company migrating from an older deployment to a newer one does not turn off the old system on day one. They run both in parallel, sometimes for years. The platform had to give them a coherent view of that mixed state, not just the endpoints that had already been modernized. That meant the analytics had to work across the full estate as it actually existed, not as a target architecture diagram imagined it should look.

What is the hardest engineering problem inside a multi-gateway analytics pipeline that nobody talks about publicly?

Data correlation at the entity level. When you have runtime traffic coming from four different gateway types, you need a reliable way to say: this call belongs to this API, this API belongs to this product, this product belongs to this team. That chain of attribution sounds obvious, but in practice it depends on identifiers being consistent across systems that were built by different teams with different conventions. When they are not consistent, and often they are not, you have to build a reconciliation layer that handles the gaps without losing data or introducing false attribution.

The other hard problem is security compliance within customer-controlled environments. Some enterprise customers operate inside VPC Service Controls, which restricts how data moves between services. Some require Customer Managed Encryption Keys. Each constraint changes how the pipeline must be architected, and you cannot simply route data through a shared processing layer and call it done. You have to design the pipeline to operate within those perimeters and then test it in network topologies that only surface in specific customer configurations. That work is invisible outside the team, but it determines whether the product is actually deployable in regulated industries.

When you were building this, what nearly caused the project to fail?

The security perimeter work almost broke the timeline twice. We had data flows that looked correct in our test environment and broke under VPC Service Controls in a customer environment, because the network topology differences changed which services could communicate with which. Diagnosing that required building out specific reproduction environments and working through ingress and egress rules across Cloud Run, Pub/Sub, Cloud Storage, and Cloud Monitoring simultaneously. It was not one misconfiguration. It was a chain of them, and each one you fixed revealed the next one downstream.

The second near-failure was grant delegation with Customer Managed Encryption Keys. When a customer uses CMEK, specific relationships between service accounts must be established for data to flow through an encrypted pipeline. We caught a gap in how we were handling delegation late enough that it required rearchitecting part of the ingestion layer under time pressure. That kind of problem is not in any documentation. You find it by running into it.

You have written publicly about where production AI systems break down. What does your experience building data infrastructure tell you about where AI at scale goes wrong most often?

The failure modes I have seen most consistently are not model failures. They are infrastructure failures that happen to involve a model. A system that worked well in testing degrades in production because the data distribution shifted and nobody had a monitor on the distribution. Or a pipeline that handled expected query volumes could not handle a 10x spike because the load testing assumptions were wrong. Or a service that was designed for synchronous request-response patterns gets asked to do something with a different latency profile and the timeouts are all wrong. None of these are problems specific to AI. They are the same problems that break any production system, and teams working on AI infrastructure often underestimate how much of the work is distributed systems engineering applied to a new workload.

The thing that I find most underestimated is the gap between what a model does in a benchmark and what it does when it is a dependency inside a larger system. A model that produces an answer 95% of the time is fine in isolation. Inside a system where five other components depend on that answer, a 5% failure rate compounds. Teams building production AI need to think about failure modes at the system level, not just at the model level. That means designing for graceful degradation, instrumenting the right signals, and testing the failure paths as carefully as they test the happy path.

You have judged engineering work across multiple technical venues. What separates submissions that hold up under scrutiny from the ones that do not?

The clearest signal is whether the team can explain what their system does when something goes wrong. Strong submissions have thought about failure modes specifically. They can tell you what happens when a dependency is slow, when data is missing, when load is three times what they designed for. Weaker submissions have usually only thought about the successful path. That gap shows up consistently across the work I have judged, including at DeveloperWeek 2026, where I served as a speaker and hackathon judge. The technical depth of a solution matters, but the quality of reasoning about its limits matters more.

The stakes for getting this right are not abstract. API attacks in the United States are projected to grow 548% by 2030. Teams building on API infrastructure now are building the systems that will need to absorb that pressure. The submissions that hold up under scrutiny are the ones that treated operational reliability and security as design constraints from the beginning, not as things to be added after the core functionality was working. That engineering discipline is what I look for, and it is what the industry is going to need more of.

If the next five years of investment in API governance goes exactly where it should, what does enterprise infrastructure look like in 2030? And what is the thing most likely to prevent that from happening?

In 2030, governance is not a separate discipline from deployment. The best-run organizations will treat an API as a managed artifact from the moment it is created: catalogued, monitored, attributed to an owner, and subject to lifecycle rules that automatically flag when it has been idle, undocumented, or operating outside its defined behavior. The analytics infrastructure to support that already exists in pieces. The missing piece is adoption, which is partly a tooling problem and partly a cultural one. Teams need to see governance as a condition of shipping, not as a compliance exercise that happens afterward.

The thing most likely to prevent that is velocity pressure. When shipping fast is the only metric that gets measured, cataloguing, documenting, and governing APIs gets deferred indefinitely. The deferral is invisible until it is not, usually when a breach happens or a migration fails because nobody can produce an accurate picture of what exists. The organizations in the best position in 2030 are the ones that decided now to treat visibility and governance as engineering work. That decision does not require new tools. It requires treating the maintenance of the API estate as seriously as the development of the APIs themselves.