When you stack a permission-check decorator and a caching decorator on one Python handler, which one must be on top?

### The rule in one line Stacked decorators execute top-down, so a layer that can **return without delegating** hides everything beneath it. A check that must run on every call therefore has to sit above any such layer. A cache is the canonical short-circuiting layer, and a permission check is the canonical must-always-run layer, which is why this specific pairing is the standard interview vehicle for the ordering question. ### What goes wrong concretely Take a handler that returns a report and is decorated with a memoising wrapper and a wrapper that raises unless the caller is an administrator. Written with the cache on top: ```python @cached @requires_admin def report(user, key): ... ``` the first call by an administrator runs the check, runs the body, and stores the result under the cache key. Every subsequent call with the same key — by anyone — hits the cache and returns the stored value immediately. The `requires_admin` wrapper is never entered. Nothing raises, nothing logs, and the behaviour is *correct on a cold cache*, which is exactly why it survives review and unit tests that exercise a single call. It is a real authorization bypass with a warm-up window. Flip the stack: ```python @requires_admin @cached def report(user, key): ... ``` Now the check is outermost. It runs on every single call, unauthorized callers are rejected before the cache is consulted, and the cache only ever serves callers who have already passed. This is the correct default. ### Generalising past this one pair The pairing is a special case of a rule worth stating explicitly, because it settles most stacking arguments: 1. **Layers that must observe every call go outermost.** Authentication and authorization, rate limiting, request-count metrics, audit logging of attempts. 2. **Layers that may short-circuit go inside those.** Caches, memoisation, feature-flag gates, circuit breakers — anything whose whole purpose is to skip work. 3. **Layers that transform inputs or outputs go where the transformation is meant to apply.** A wrapper that normalises arguments must sit above the cache if the cache is to key on normalised arguments; a wrapper that serialises the result sits below the cache if you want the serialised form cached, and above it if you want the raw object cached. 4. **Layers that must see the real body** — timing the actual work, retrying the actual work — go innermost, because anything above them measures or retries the layers in between as well. Applying rule 3 shows the ordering question is not only about security. If argument normalisation sits *below* the cache, two calls that differ only cosmetically produce two different cache keys and the hit rate collapses; move it above the cache and they collapse into one key. Neither placement raises an error; only one is what you meant. ### The cache-key half of the problem Ordering fixes *whether* the check runs; it does not by itself make a shared cache safe. If the cached value differs per caller, the caller's identity must be part of the cache key as well — otherwise the check correctly rejects unauthorized callers while authorized caller A is served the value computed for authorized caller B. In review, treat "is the check above the cache?" and "does the key include everything the value depends on?" as two separate questions, both of which must be answered yes. ### Reasoning about it in an interview The way to derive the answer rather than recall it: rewrite the stack as nested calls and ask what happens on the *second* call. `cached(requires_admin(report))` — the second call enters `cached`'s wrapper, finds the key, returns. Nothing else executes. `requires_admin(cached(report))` — the second call enters `requires_admin`'s wrapper, which raises or delegates, and only then reaches `cached`. Once you can say "which layer can return early, and what does it hide?" the ordering is mechanical, and the same sentence answers the rate-limit, feature-flag and circuit-breaker versions of the question without any new memorisation. ### The failure mode to name The reason interviewers like this question is that the wrong order fails *asymmetrically*: it is correct on the first call and wrong afterwards, so it passes the obvious test, produces no exception, and only misbehaves once the process has been running long enough to have a populated cache. Being able to say that out loud — "this is a bug that only appears after warm-up" — is what separates a candidate who has reasoned about stacking from one who has memorised the direction.