If Every Access Request Requires a Security Decision, Latency Becomes a Security Problem

Zero Trust places security directly in the path of everyday work. 

An employee opens an internal application. A developer connects to a protected resource. A contractor requests access to the system they have been assigned. 

Before that interaction can continue, the platform may need to verify identity, evaluate device trust, check applicable policies and determine whether the requested resource should be accessible. 

The stronger the access model becomes, the more important the speed of that decision becomes. 

A policy engine may be technically accurate, but if users regularly wait for it, security becomes visible as friction. 

That creates an unusual engineering requirement for Zero Trust platforms: security decisions need to be rigorous enough to protect access and fast enough to almost disappear from the user experience. 

The challenge becomes much larger as traffic grows. 

At a few thousand requests, an inefficient service may be inconvenient. At tens of millions of requests every day, the same inefficiency becomes an architectural issue. 

One Zero Trust platform we have worked on now processes more than 50 million API requests daily, exceeding 350 million requests in a week. Average throughput sits at around 600 requests per second, with peaks approaching 850 requests per second. 

Yet its median response time remains around 30 milliseconds, with the vast majority of requests completing within approximately 200 milliseconds. During the supplied recent production period, its error rate remained below 0.2%. 

At the current rate, the platform is processing more than 20 billion requests annually. 

Those numbers say something important about security architecture. 

Performance cannot be treated as an optimisation exercise that happens after security capabilities have been built. Identity integrations, policy evaluation, device authentication, secure connectivity and the infrastructure underneath them form part of the same user journey. A bottleneck anywhere along that path can affect how quickly access is granted. 

The architecture supporting those decisions therefore matters just as much as the policies themselves. 

In this instance, a Go and MySQL core evolved across GCP and AWS as the platform expanded to thousands of customer organisations and more than a dozen global points of presence. Some services could be extended as demand changed. Others had to be redesigned or completely rewritten while the live platform continued serving existing customers. 

The objective throughout was straightforward: increased security sophistication could not come at the expense of the experience of using the system. 

That is an important benchmark for Zero Trust engineering. 

Users should experience the result of a security decision. They should rarely have to experience the work required to make it.