Explain precisely why the ThreadLocal-based SecurityContextHolder breaks on WebFlux's event loop, and what replaces it.

## Thread-per-request vs event loop Spring MVC on the Servlet stack dedicates **one thread to a request** from the moment the container accepts it until the response is written. Because the thread == the request, storing per-request state in a **`ThreadLocal`** is safe and cheap. That is exactly what `SecurityContextHolder` does with `SecurityContextHolderStrategy` (default `ThreadLocalSecurityContextHolderStrategy`). `SecurityContextPersistenceFilter`/`SecurityContextHolderFilter` sets it at the start and clears it in a `finally` at the end. WebFlux uses the **reactive / event-loop model** (Reactor Netty by default). There is a small, fixed set of **event-loop threads** — usually one per CPU core. These threads must never block; instead each unit of work is small and non-blocking, and threads are reused across all in-flight requests. ## Why the ThreadLocal fails — two independent reasons 1. **Interleaving (sharing one thread across requests):** one event-loop thread processes fragments of request R1, then R2, then R1 again. A ThreadLocal has exactly one slot per thread, so it cannot simultaneously hold R1's and R2's user. Whatever was last written wins, so you'd read the wrong principal. 2. **Thread hopping (one request across threads):** a reactive pipeline can switch threads at operators like `flatMap`, `publishOn`, `subscribeOn`, or when an async I/O callback resumes on a different event-loop thread. A value written to the ThreadLocal on thread A is simply not present on thread B. Even a single, isolated request would lose the context mid-chain. Either reason alone is fatal; together they make ThreadLocal unusable for security state on WebFlux. ## What replaces it: the Reactor Context Project Reactor provides **`Context`** (accessed via `ContextView`) — an **immutable** key/value map that is **attached to the subscription**, i.e. to the reactive chain for one request, *not* to any thread. Its properties: - It travels with the data flow regardless of which thread executes an operator, so thread hopping is a non-issue. - Each subscription has its own context, so interleaving on a shared thread is a non-issue. - It is immutable and flows **from the subscriber upstream toward the source** (written with `contextWrite`, formerly `subscriberContext`), then is visible to operators reading it with `Mono.deferContextual` / `Flux.deferContextual`. Spring Security stores the `SecurityContext` under a well-known key in the Reactor Context. `ReactiveSecurityContextHolder.getContext()` is essentially a `Mono.deferContextual` that looks up that key. Method security (`ReactiveMethodSecurity`, `@PreAuthorize`) and `@AuthenticationPrincipal` read the same context, so authorization works consistently. ## The mental model / gotcha - 'Per-thread' (ThreadLocal) → replaced by 'per-subscription' (Reactor Context). - You cannot smuggle the value across an unrelated `subscribe()` — the context only exists inside the connected chain you return from the handler. - Mixing blocking libraries that read `SecurityContextHolder` into a WebFlux app is a real trap: they'll see an empty ThreadLocal. Bridging requires the Micrometer context-propagation library (covered separately). ## When it matters in interviews This question separates candidates who 'use WebFlux' from those who understand *why* the reactive stack needed its own security propagation mechanism. The crisp answer is: ThreadLocal assumes thread==request; the event loop breaks that assumption in two ways, so state moves to the subscription-scoped Reactor Context.