Support told me a screen in the moderation panel took about three seconds to load. I profiled the endpoint behind it and the handler came back fast: query, serialization, all of it well inside budget.
The time was not in the endpoint. It was in everything that ran before it.
Every request to that payment platform re-validated the bearer token against the OAuth service, then expanded the caller's roles into an effective permission set, a walk across the access model, once per request. And the panel did not make one request per screen. It made a dozen in parallel. So one page load meant a dozen introspection round trips and a dozen permission expansions against a service nobody had sized for that.
The endpoint I was asked to optimize was innocent. The slow part had no owner, because nobody thought of it as part of the request at all.
Two things changed after that.
I measure request time in two halves (before the handler, and inside it), so middleware cost stays visible instead of folded into one number.
And authorization state gets computed when a token is issued, not when it is used. The request path reads a materialized permission set and checks a revocation list. Nothing more.
Access control is request-path code. If it does not show up in your timings at all, that does not make it cheap: it makes it unmeasured.
I write these up in longer form on my blog: https://polycratia.com/c/8aec660e
Curious how others settle this one: you cache token introspection, or you push permissions into the token and live with the revocation lag...