Introduction

Java code has traditionally treated thread blocking as normal. Call a database, the thread sits there waiting. Hit an external API, it idles. Under load this wastes resources.

Reactive programming inverts this. Instead of blocking while you wait, you register a callback and move on. The result arrives whenever it arrives, and something else handles the notification. Spring WebFlux shipped this model as a mainstream option.

WebFlux landed in Spring Framework 5.0 as a fully non-blocking web framework built on reactive streams. It runs on servers like Netty without servlet container overhead. WebFlux implements the Reactive Streams specification through Project Reactor, so every operator and backpressure mechanism follows a shared contract.

The benefit is throughput. A blocking server exhausts its thread pool under load. A WebFlux server handles more concurrent requests on the same hardware, because threads never sit idle waiting for network responses.

Spring WebFlux & Reactive: Mono, Flux & WebClient

Project Reactor Core Types

Project Reactor is the reactive library that powers WebFlux. It has two primary types, and getting comfortable with both is prerequisite to anything else.

Mono

Mono represents a pipeline that emits zero or one element. Think of it as an async Optional, or a CompletionStage that can also be empty. You reach for Mono when an operation yields a single result or nothing at all.

Mono<User> findById(Long id);
Mono<Void> save(User user);
Mono<Boolean> existsByUsername(String username);

The empty case deserves attention. A Mono can complete without emitting any value at all, which is meaningfully different from “no result found” in blocking code. Your code has to handle both the value-present and the empty-complete paths.

Flux

Flux represents a pipeline that emits zero to n elements. It is the reactive equivalent of a Stream, except it can also signal completion or an error. You use Flux when an operation might return multiple results.

Flux<User> findAll();
Flux<Order> findByCustomerId(Long customerId);

Both Mono and Flux are lazy. Nothing runs until you subscribe. This is a fundamental shift from imperative code where calling a method executes it immediately. With reactive types, calling findAll() does not hit the database — it builds a description of a pipeline that will hit the database when something subscribes.

Key Operators

Reactor ships with an enormous operator library. A handful show up constantly in actual applications.

map transforms each element in the pipeline. It runs synchronously on whatever thread the previous step was using.

Flux<User> activeUsers = userRepository.findAll()
    .filter(user -> user.isActive())
    .map(user -> user.toSummaryDto());

flatMap transforms each element into a Mono or Flux and then merges all those nested pipelines into one. This is how you chain asynchronous operations.

Flux<OrderDto> orderDtos = orderRepository.findByCustomerId(id)
    .flatMap(order -> productService.fetchProduct(order.getProductId())
        .map(product -> new OrderDto(order, product)));

zip combines multiple reactive pipelines pairwise. Both inputs need to emit the same number of elements, and zip fires whenever all sources have each emitted a new item.

Mono<CombinedReport> report = Mono.zip(
    userService.fetchUser(id).single(),
    orderService.fetchRecentOrders(id).collectList(),
    (user, orders) -> new CombinedReport(user, orders)
);

switchIfEmpty substitutes an alternative Mono when the source completes without emitting. It handles the empty case without throwing.

Mono<Cart> cart = cartRepository.findByUserId(id)
    .switchIfEmpty(Mono.just(Cart.empty(userId)));

When to Use Reactive — And When Not To

Reactive programming solves real problems. It also introduces complexity that is not always justified. Here is how to think it through.

Choose Reactive When

You are building a system that fans out to multiple external services. If service A takes 100ms, B takes 150ms, and C takes 80ms, calling them sequentially in blocking code costs 330ms. Calling them reactively with flatMap or zip costs roughly 150ms — the slowest one. That math adds up fast at scale.

You are building a data streaming endpoint. Server-sent events, WebSocket streams, anything where data arrives incrementally maps naturally to Flux.

You are using a database with a reactive driver. R2DBC works for relational databases, and reactive MongoDB and Cassandra drivers are solid. If your database has no reactive driver, you are blocking anyway, and the complexity is pure overhead.

Avoid Reactive When

Your team is new to reactive programming. The debugging experience is genuinely different. Stack traces span multiple threads. NullPointerException inside an operator behaves oddly. Tracking down a blocking call buried in a reactive chain can eat half a day.

Your dependencies do not support reactive. Wrapping blocking calls in Mono.fromCallable() or Schedulers.boundedElastic() technically works, but you have just hidden the blocking. The thread pool managing those calls becomes your bottleneck and your blast radius.

Simple CRUD with no meaningful concurrency needs? Just use Spring MVC. It is easier to write, easier to debug, and easier to hand off to the next developer.

Trade-off Table

Factor	Blocking (Spring MVC)	Reactive (WebFlux)
Thread utilization	Poor under I/O wait	High — threads never block
Throughput under load	Limited by thread pool size	High — event-loop based
Learning curve	Low	Steep — new mental model
Debugging	Familiar stack traces	Multi-thread, async stack traces
Ecosystem support	Universal JDBC drivers	Reactive drivers only
Backpressure	Not built in	Native via Reactive Streams spec
Memory per connection	One thread ~1MB stack	A few kilobytes
Code readability	Straightforward	Requires operator fluency
Right fit	Simple CRUD, CPU-bound	I/O-heavy, high concurrency

Reactive Flow Architecture

Understanding the path a request takes through a reactive system is worth your time. Here is how a typical call moves through the stack.

graph TD
    A["Client Request"] --> B["Netty Event Loop"]
    B --> C["WebFlux DispatcherHandler"]
    C --> D["Handler Function / Controller"]
    D --> E["Service Layer<br/>Mono / Flux"]
    E --> F["Reactive Repository<br/>R2DBC / Reactive Mongo"]
    F --> E
    E --> G["Data Transform Operators"]
    G --> H["Response Encoding"]
    H --> I["Client Response"]

The Netty event loop never blocks waiting for the database. When the database responds, the event loop picks up the continuation and resumes the pipeline. This is the core mechanism that lets a handful of threads handle massive concurrency.

Implementation Snippets

Annotation-Based Controller

The annotation-based style looks familiar if you have used Spring MVC. The key difference is the return types.

@RestController
@RequestMapping("/api/users")
public class UserController {

    private final UserRepository userRepository;

    public UserController(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    @GetMapping("/{id}")
    public Mono<ResponseEntity<UserDto>> getUser(@PathVariable Long id) {
        return userRepository.findById(id)
            .map(user -> ResponseEntity.ok(user.toDto()))
            .defaultIfEmpty(ResponseEntity.notFound().build());
    }

    @GetMapping
    public Flux<UserDto> getAllUsers(
            @RequestParam(defaultValue = "0") int page,
            @RequestParam(defaultValue = "20") int size) {
        return userRepository.findAll()
            .skip((long) page * size)
            .take(size)
            .map(User::toDto);
    }

    @PostMapping
    public Mono<ResponseEntity<UserDto>> createUser(
            @RequestBody @Valid UserCreateRequest request) {
        return userRepository.save(request.toEntity())
            .map(user -> ResponseEntity
                .created(URI.create("/api/users/" + user.getId()))
                .body(user.toDto()));
    }

    @DeleteMapping("/{id}")
    public Mono<ResponseEntity<Void>> deleteUser(@PathVariable Long id) {
        return userRepository.deleteById(id)
            .then(Mono.just(ResponseEntity.noContent().<Void>build()));
    }
}

Functional Routing Configuration

Functional routing separates routing configuration from the actual handler logic. Routes are defined as a bean returning a RouterFunction.

@Configuration
public class UserRoutingConfig {

    @Bean
    public RouterFunction<ServerResponse> userRoutes(UserHandler userHandler) {
        return route()
            .GET("/api/users/{id}", userHandler::getUser)
            .GET("/api/users", userHandler::getAllUsers)
            .POST("/api/users", userHandler::createUser)
            .DELETE("/api/users/{id}", userHandler::deleteUser)
            .build();
    }
}

The handler receives ServerRequest objects instead of method parameters parsed by annotations.

@Component
public class UserHandler {

    private final UserRepository userRepository;

    public UserHandler(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public Mono<ServerResponse> getUser(ServerRequest request) {
        Long id = Long.parseLong(request.pathVariable("id"));
        return userRepository.findById(id)
            .map(user -> ServerResponse.ok().bodyValue(user.toDto()))
            .defaultIfEmpty(ServerResponse.notFound().build())
            .flatMap(sr -> sr);
    }

    public Mono<ServerResponse> getAllUsers(ServerRequest request) {
        return ServerResponse.ok()
            .body(userRepository.findAll().map(User::toDto), UserDto.class);
    }

    public Mono<ServerResponse> createUser(ServerRequest request) {
        return request.bodyToMono(UserCreateRequest.class)
            .flatMap(userRepository::save)
            .map(user -> ServerResponse
                .created(URI.create("/api/users/" + user.getId()))
                .bodyValue(user.toDto()))
            .flatMap(sr -> sr);
    }
}

WebClient with Retry and Timeout

WebClient is the reactive HTTP client that comes with WebFlux. It replaces RestTemplate in reactive applications.

@Configuration
public class ExternalApiConfig {

    @Bean
    public WebClient webClient(WebClient.Builder builder) {
        return builder
            .baseUrl("https://api.example.com")
            .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
            .build();
    }
}

@Service
public class ProductService {

    private final WebClient webClient;

    public ProductService(WebClient webClient) {
        this.webClient = webClient;
    }

    public Mono<ProductSummary> fetchProductSummary(String productId) {
        return webClient.get()
            .uri("/products/{id}/summary", productId)
            .retrieve()
            .bodyToMono(ProductSummary.class)
            .retryWhen(Retry.backoff(3, Duration.ofMillis(200))
                .filter(ex -> ex instanceof WebClientResponseException.ServiceUnavailable)
                .doBeforeRetry(signal -> {
                    System.err.println("Retrying after: " + signal.failure().getMessage());
                }))
            .timeout(Duration.ofMillis(1500))
            .onErrorResume(WebClientResponseException.class,
                ex -> Mono.just(ProductSummary.unavailable(productId)));
    }

    public Flux<Review> fetchReviews(String productId) {
        return webClient.get()
            .uri("/products/{id}/reviews", productId)
            .retrieve()
            .bodyToFlux(Review.class)
            .take(10)
            .timeout(Duration.ofSeconds(5))
            .onErrorResume(Exception.class, ex -> Flux.empty());
    }
}

The retry policy uses exponential backoff and filters to retry only on service-unavailable errors, not 404s or 400s. The timeout operator prevents calls from hanging forever, and onErrorResume provides a graceful fallback.

Failure Scenarios

Backpressure Mishandling

Reactive streams carry backpressure — the downstream consumer can signal the upstream to slow down. In theory this prevents memory exhaustion. In practice, if you have a Flux emitting thousands of items per second and your database write cannot keep up, buffering kicks in. With no limit, you run out of memory.

Use .limitRate() or .onBackpressureBuffer() intentionally.

// Buffers everything — dangerous with large datasets
userRepository.findAll()
    .map(this::processUser)
    .subscribe();

// Backpressure applied — processes 100 items at a time
userRepository.findAll()
    .limitRate(100)
    .flatMap(this::processUser)
    .subscribe();

Blocking Inside Reactive Pipelines

Sometimes a blocking call slips into a map() or flatMap(). The code compiles. It might pass unit tests. In production it deadlocks the event loop thread and your server stops handling requests entirely.

// This compiles but will deadlock your server under load
userRepository.findAll()
    .map(user -> someBlockingLegacyService.getInfo(user.getId()))
    .subscribe();

The fix is moving the blocking call to a separate scheduler.

userRepository.findAll()
    .flatMap(user -> Mono.fromCallable(() ->
        someBlockingLegacyService.getInfo(user.getId()))
        .subscribeOn(Schedulers.boundedElastic()))
    .subscribe();

boundedElastic is the scheduler for blocking calls. It manages a bounded thread pool for exactly this situation. Do not use it on hot paths, but it is the right escape hatch when you need it.

Null in Reactive Streams

Reactive streams do not allow null values. Emitting null is treated the same as completing the stream with an error. If your method might return null, wrap it.

// Throws NullPointerException at runtime
userRepository.findById(999L)
    .map(user -> user.getNickname())
    .subscribe();

// Wrap nullable values in Optional
userRepository.findById(999L)
    .map(user -> Optional.ofNullable(user.getNickname()))
    .subscribe();

Memory Leaks from Unsubscribed Pipelines

If you create a Flux from a hot source — a message queue, a Kafka consumer — and never subscribe, the source keeps buffering messages. Always track your subscriptions and cancel them when the owning component is destroyed.

private Flux<Message> messageStream;

@PostConstruct
public void init() {
    messageStream = messageBroker.subscribe("topic").share();
}

@Override
public void dispose() {
    messageStream.subscribe().dispose();
}

Spring’s @PreDestroy and DisposableBean patterns work here. Make sure reactive components clean up after themselves.

Observability Checklist

Reactive streams can hide latency problems that are obvious in blocking code. A slow call in a blocking system shows up immediately in the thread stack. With reactive, you need explicit instrumentation.

Logging

Project Reactor provides a debugging helper that instruments operators with checkpoint descriptions.

// Enable at startup to instrument all operators
Hooks.enableRecycledChecks();

userRepository.findAll()
    .map(user -> processUser(user))
    .checkpoint("UserProcessing.fetchAndProcess")
    .subscribe();

For production, use ContextualLogging via the log() operator, which attaches context across async boundaries.

userRepository.findAll()
    .flatMap(user -> processUser(user))
    .contextWrite(ctx -> ctx.put("requestId", requestId))
    .log("com.example.user-service")
    .subscribe();

Metrics

Micrometer integrates with Project Reactor through ReactorMetrics. Register the meter registry and reactive pipelines automatically report subscription timings.

@Bean
public ReactiveWebServerFactoryAccountant reactorMetrics(MeterRegistry registry) {
    return new ReactorNettyMeterBinder(registry);
}

Metrics worth watching:

• reactor.subscribed — active subscriptions
• reactor.flowed — items that passed through the pipeline
• reactor cancelled — subscriptions that cancelled early
• HTTP client metrics: connect time, response time, retry count

Security Notes

Security in WebFlux uses a different model than Spring Security’s servlet filter chain. WebFlux uses WebFilter chains composed of ServerWebFilter instances.

Basic Authentication with WebFilter

@Configuration
@EnableWebFluxSecurity
public class SecurityConfig {

    @Bean
    public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http) {
        return http
            .csrf(ServerHttpSecurity.CsrfSpec::disable)
            .authorizeExchange(exchanges -> exchanges
                .pathMatchers("/public/**").permitAll()
                .pathMatchers("/api/admin/**").hasRole("ADMIN")
                .anyExchange().authenticated())
            .httpBasic(Customizer.withDefaults())
            .build();
    }
}

JWT in WebFlux

JWT authentication in reactive context requires reactive token validation.

@Component
public class JwtAuthenticationWebFilter implements WebFilter {

    private final JwtTokenProvider jwtTokenProvider;

    public JwtAuthenticationWebFilter(JwtTokenProvider jwtTokenProvider) {
        this.jwtTokenProvider = jwtTokenProvider;
    }

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
        String path = exchange.getRequest().getPath().value();
        if (path.startsWith("/public")) {
            return chain.filter(exchange);
        }

        return jwtTokenProvider.validateTokenAsync(
                exchange.getRequest().getHeaders().getFirst("Authorization"))
            .flatMap(claims -> {
                if (claims != null) {
                    String username = claims.getSubject();
                    List<SimpleGrantedAuthority> authorities = extractRoles(claims);
                    return chain.filter(
                        exchange.mutate()
                            .principal(new UsernamePasswordAuthenticationToken(
                                username, null, authorities))
                            .build());
                }
                return chain.filter(exchange);
            })
            .switchIfEmpty(chain.filter(exchange));
    }
}

Rate Limiting

Rate limiting works as a WebFilter that tracks request counts per IP using a concurrent map.

@Component
public class RateLimitingWebFilter implements WebFilter {

    private final Map<String, AtomicInteger> requestCounts = new ConcurrentHashMap<>();
    private static final int MAX_REQUESTS = 100;

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) {
        String clientIp = exchange.getRequest().getRemoteAddress()
            .getAddress().getHostAddress();
        AtomicInteger count = requestCounts.computeIfAbsent(clientIp, k -> new AtomicInteger(0));

        if (count.incrementAndGet() > MAX_REQUESTS) {
            exchange.getResponse().setStatusCode(HttpStatus.TOO_MANY_REQUESTS);
            return exchange.getResponse().setComplete();
        }

        return chain.filter(exchange)
            .doFinally(signal -> count.decrementAndGet());
    }
}

Common Pitfalls / Anti-Patterns

Block-Hunting

Never call block() or blockFirst() on a reactive pipeline from an event loop thread. If you need the result synchronously at some boundary, use toFuture() at the edge of your system, not in the middle of a reactive chain.

// WRONG — blocks the event loop thread
@GetMapping("/sync")
public UserDto getUser(Long id) {
    return userRepository.findById(id).block();
}

// CORRECT — return reactive type from controller
@GetMapping("/async")
public Mono<ResponseEntity<UserDto>> getUser(Long id) {
    return userRepository.findById(id)
        .map(user -> ResponseEntity.ok(user.toDto()))
        .defaultIfEmpty(ResponseEntity.notFound().build());
}

subscribe() Variants

The subscribe() method has several overloads. The no-arg variant swallows errors silently.

// Silent failures — errors go nowhere
userRepository.findAll().subscribe();

// Handle each signal explicitly
userRepository.findAll()
    .subscribe(
        item -> processItem(item),
        error -> logger.error("Failed", error),
        () -> logger.info("Completed"));

In tests, always use StepVerifier.

@Test
public void testGetUser() {
    StepVerifier.create(userRepository.findById(1L))
        .expectNextMatches(user -> user.getName().equals("Alice"))
        .verifyComplete();
}

@Test
public void testNotFound() {
    StepVerifier.create(userRepository.findById(999L))
        .verifyComplete();  // completes without emitting = not found
}

concatMap vs flatMap

Both flatten nested reactive pipelines, but they behave differently.

flatMap subscribes to all inner pipelines immediately and interleaves their outputs as they arrive. Order is not preserved. Use it for independent operations that can run concurrently.

// A, B, C start simultaneously, results interleave as they complete
userRepository.findAll()
    .flatMap(user -> externalService.enrich(user))
    .subscribe();

concatMap subscribes to the next inner pipeline only after the previous one completes. Order is preserved, but operations run sequentially.

// Processes A completely, then B, then C
userRepository.findAll()
    .concatMap(user -> writeToAuditLog(user))
    .subscribe();

Mixing these up causes subtle correctness bugs. flatMap for independent concurrent work, concatMap when order matters or operations must not overlap.

Production Failure Scenarios

Reactive systems fail in ways that look nothing like blocking code failures.

Blocking the Event Loop Thread

A blocking call buried inside a reactive pipeline deadlocks the event loop thread. The code compiles, unit tests pass in isolation, and production grinds to a halt. The symptom is sessions timing out across the entire service, not just on the endpoint making the bad call. Common culprits: jdbcTemplate.queryForObject() inside a map(), a synchronous cache lookup inside a flatMap(), any call to a blocking library that has no reactive alternative. Profile blocking calls with Schedulers.assertThatOperatorsAreNotBlocking() in tests. Move blocking operations to Mono.fromCallable() with subscribeOn(Schedulers.boundedElastic()).

null Emission Triggering NPE in Pipelines

Reactive streams do not allow null values. Emitting null is treated the same as completing with an error. If your database query returns no results and you map that to null instead of Mono.empty(), the pipeline throws a NullPointerException at subscription time. This is particularly insidious because the error happens far from where the null originated. Always wrap nullable values in Optional. Use switchIfEmpty() to handle the empty case explicitly rather than relying on null.

Hot Source Memory Leaks from Unsubscribed Streams

A Flux created from a hot source like a message queue or Kafka consumer keeps buffering messages if no subscription exists. If your application receives messages but the consumer is never subscribed, those messages accumulate in the source’s internal buffer until memory is exhausted. Always track subscriptions and cancel them in @PreDestroy or DisposableBean.dispose(). Use share() or publish() with explicit subscription management rather than assuming the pipeline will clean itself up.

Backpressure Mishandling Causing Memory Exhaustion

A Flux emitting thousands of items per second that meets a slow consumer buffers everything by default. Without .limitRate() or explicit backpressure configuration, memory grows until the application crashes or the consumer catches up. The fix is applying .limitRate() or .onBackpressureBuffer() with an explicit overflow strategy. Choose the strategy based on your failure mode: drop new events, drop old events, or signal backpressure to the producer.

Quick Recap Checklist

• Mono emits 0-1 elements; Flux emits 0-n. Pick based on how many results your operation produces.
• Nothing runs until you subscribe. Reactive pipelines are lazy by design.
• Blocking inside a reactive chain deadlocks the event loop. Move blocking calls to Schedulers.boundedElastic().
• Reactive streams do not allow null. Wrap nullable values in Optional.
• Use .limitRate() or .onBackpressureBuffer() to prevent memory exhaustion on large streams.
• WebClient replaces RestTemplate in reactive applications. Use it for all HTTP calls.
• Attach retry and timeout to every external HTTP call.
• .switchIfEmpty() handles the empty Mono case without throwing.
• flatMap interleaves concurrent work; concatMap preserves order.
• Use StepVerifier in tests. Never use no-arg subscribe() in production.
• WebFlux security uses WebFilter, not servlet filters.
• Cancel hot streams on component destroy to avoid resource leaks.
• Use checkpoint() or log() for observability across async boundaries.
• Functional routing is worth considering for new WebFlux applications — it is more explicit and easier to test than annotation-based controllers.

Interview Questions

Further Reading

R2DBC Deep Dive

R2DBC (Reactive Relational Database Connectivity) is the cornerstone of fully reactive Spring applications with relational databases. Unlike JDBC’s synchronous model, R2DBC exposes database operations as Mono and Flux types, enabling true end-to-end non-blocking data access. Spring Data R2DBC provides repository abstractions that return reactive types, and the DatabaseClient gives you fine-grained control over queries and transactions. R2DBC also introduces backpressure at the database layer, which means slow consumers can signal the database to slow down, preventing unbounded memory growth. Pair R2DBC with reactive transaction management via @Transactional for consistent data access across multiple operations.

WebSocket & Server-Sent Events (SSE) in WebFlux

WebFlux has first-class support for WebSocket connections and Server-Sent Events, both of which map naturally to reactive streams. A WebSocket endpoint returns a Flux<WebSocketMessage> in each direction, letting you process incoming and outgoing messages reactively. SSE endpoints return a Flux<ServerSentEvent> which WebFlux encodes automatically. Both work seamlessly with backpressure — if a client reads slowly, the server buffers within configured limits rather than accumulating unbounded data. For real-time dashboards or notification systems, WebSocket and SSE in WebFlux provide better resource efficiency than polling or long-polling alternatives.

Testing WebFlux Applications

Testing reactive code requires different tools than testing blocking code. StepVerifier is the primary tool — it subscribes to a reactive pipeline and asserts each expected signal. For unit testing controllers, WebTestClient binds to your router or controller and lets you assert the response with StepVerifier. For integration testing, MockServerHttpRequest and MockServerHttpResponse simulate HTTP interactions without a real server. Always test error paths: use verifyError() or verifyErrorMatches() in StepVerifier. For performance testing, Project Reactor provides FluxSink.next() backpressure tests. Profile blocking calls in tests with Schedulers.assertThatOperatorsAreNotBlocking() to catch accidental blocking calls before they reach production.

Conclusion

Spring WebFlux represents a fundamental shift in how Java applications handle concurrency. Rather than dedicating a thread to each blocking I/O operation, WebFlux uses an event-loop model that can handle thousands of concurrent connections with a small number of threads. The payoff is dramatic throughput improvements for I/O-bound workloads, but the cost is a steeper learning curve and debugging experience that differs significantly from traditional blocking code.

The key to successful WebFlux adoption is recognizing when the tradeoff makes sense. High-concurrency scenarios with multiple external service calls, streaming data endpoints, and applications that need to handle thousands of concurrent long-lived connections are WebFlux’s natural habitat. Simple CRUD operations with no meaningful concurrency needs are better served by Spring MVC. The ecosystem matters too: without reactive database drivers, you inherit blocking at the persistence layer and lose the core benefit.

If you do adopt WebFlux, invest heavily in the team’s operator fluency and testing practices. Reactive pipelines that compile and pass unit tests can still deadlock production servers when a blocking call slips into an operator chain. Schedulers.assertThatOperatorsAreNotBlocking() in tests catches these before they reach production. The observability story requires explicit instrumentation too — where blocking code shows up in thread stacks naturally, reactive code needs checkpoint() and Micrometer integration to be traceable.