Spring WebFlux consumes external data non-blockingly using WebClient, whose responses are handled as reactive Mono/Flux streams so the calling thread is never blocked waiting on I/O.
Key Points: • WebClient.get().uri(...).retrieve() issues the call without blocking the current thread. • bodyToMono() is used for a single expected object; bodyToFlux() is used for a stream of multiple items. • Operators like map(), filter(), and flatMap() transform the data reactively as it arrives, without waiting for the entire response to complete first. • Backpressure is handled automatically by the reactive streams implementation, preventing a fast producer from overwhelming a slow consumer. • The whole chain stays non-blocking end to end only if downstream code also avoids blocking calls (e.g. no .block() in request-handling paths).
Example: Fetching a stream of stock price updates with WebClient returns a Flux<PriceUpdate> that the application can filter for a specific symbol and map into a display format as each update arrives, without ever pausing the thread to wait.
Code Example:
public Flux<PriceUpdate> streamPrices(String symbol) {
return webClient.get()
.uri("/prices/stream")
.retrieve()
.bodyToFlux(PriceUpdate.class)
.filter(p -> p.getSymbol().equals(symbol));
}Interview Tip: A concise interview answer is:
"I'd use WebClient's non-blocking get().retrieve() and map the response into a Mono or Flux depending on whether I expect one item or a stream. From there, operators like map and filter let me process the data reactively as it arrives, keeping the whole pipeline non-blocking end to end."