Middleware hooks are registered from several startup modules — how do you pin down the effective chain order and break ties?

## What actually decides the order 'Registration order' is the default answer, not the complete one. In most frameworks several signals combine, and they are consulted in a definite precedence: | Signal | Typical effect | How stable is it | |---|---|---| | explicit order or priority value | sorts the whole set; usually wins outright | stable, but only if values are distinct | | named phase or stage | fixes a coarse sequence; position matters only within a stage | stable, coarse-grained | | registration call sequence | orders everything the signals above leave equal | stable only within one registration site | | discovery or scan order | orders what nobody registered explicitly | unstable; can change on rename or repackaging | | attachment scope | a separate axis: broad and narrow attachments interleave by the framework's rule | framework-specific; read the manual | The first practical step in any real codebase is to find out which of these your framework applies and in what precedence, because a plan built on the wrong assumption fails silently rather than loudly. ## Why ties are dangerous A tie is two hooks the ordering rule cannot separate: same priority number, same phase, no explicit position. Frameworks almost never reject that configuration — they resolve it with whatever is at hand, which might be the order registration calls ran, the order components were discovered, or a name comparison. The result is an order that is real, reproducible today, and **not derived from anything you wrote down**. That is why the failure is so nasty. Nothing changes in the hooks; someone adds a module, renames a file, or reorders a list of startup steps, and the effective chain quietly reshuffles. If the tied pair happened to be a guard and the work it guards, the reshuffle is a security regression with no diff that looks like one. - **Never leave an ordering-sensitive pair tied.** If the relative order of two hooks matters at all, state it. - **Distinct values, not equal ones.** Two hooks sharing a priority number are tied even though both look configured. - **A single registration site beats clever numbers**, when you can have it: a readable list in one place is the easiest ordering to audit. ## Ordering as a correctness constraint The reason to spend effort here is that some orderings are not preferences but requirements, and the requirement is usually about *what must not happen yet*: 1. **A guard must be entered before the work it guards.** If a hook that authenticates the caller sits behind a hook that reads, parses and logs the request body, then unauthenticated input has already been consumed and written to logs by the time anybody checks who sent it. The rejection still returns the right status, and the damage is already done. 2. **A hook that must wrap everything has to be outermost**, which means first in the effective order — timing, outgoing-body transformation, and anything whose whole value is that it covers all traffic. 3. **Expensive work belongs inside cheap rejections**, so a request that is going to be refused is refused before the expense is incurred. Write these down as **constraints between pairs** — *A before B, and here is why* — rather than as a single fixed list. Constraints survive the arrival of a seventh hook; a list does not, because the next person has no way to know where the new one belongs. ## Making the order observable Order is invisible in the source when registration is spread out, so make it visible somewhere else: - **Print the composed chain at startup.** Many frameworks can enumerate it; if yours cannot, the registration layer you own usually can, and one log line at boot answers the question forever. - **Assert it.** A test that composes the application and checks the resulting sequence against the written-down constraints turns a silent reshuffle into a failing build — which is the only mechanism that actually catches the rename-induced reorder described above. - **Trace one request.** If each hook records its entry, a single request's trace shows the real order, including any interleaving from attachment scope that static reading of the startup code would miss. ## What interviewers are checking The junior answer is 'they run in the order you register them'. The senior answer is that registration order is only the fallback, that ties are resolved by something incidental, that ordering-sensitive relationships must be stated explicitly, and that the order should be observable rather than inferred. Bonus signal: naming a specific pair whose inversion is a real bug, and explaining what was lost — not merely that it was 'wrong'.