Mono and Flux Microservice with Reactive Java

Table of Contents

1. Challenge

   Step 1: Implement the first endpoint

   Modern APIs live or die by how well they handle concurrent load, and building services that react to requests instead of blocking on them is at the heart of solving that. In this lab, you take the Spring Boot application from the Mono and Flux Microservice with Reactive Java course and add the pieces that make it fully reactive, using Project Reactor and Spring WebFlux.

   You'll add Mono- and Flux-based endpoints, compose a flatMap-based pipeline that groups stock quotes by industry, implement manual backpressure with a custom Subscriber, stream live updates with Server-Sent Events, and offload a blocking balance check to a virtual thread. Your starter code in the application directory already has the Spring WebFlux dependency wired in, along with a ReactionControllerOne class waiting for its logic. Step 1 gets you started by implementing its first endpoint, which doubles as confirmation that Project Reactor's core reactive types are available and working.

2. Challenge

   Step 2: Build Mono and Flux endpoints

   With your first Mono endpoint confirmed and working, you're ready to add a Flux-returning service and endpoint. In this step, you implement a service that returns a Flux<StockQuote> of simulated data, then wire a second, self-contained Flux-returning endpoint that transforms and filters that data with map and filter. By the end of this step, your application exposes both single-value and multi-value reactive endpoints that Spring WebFlux subscribes to on your behalf.

3. Challenge

   Step 3: Compose a reactive pipeline with backpressure

   Your endpoints now return Mono and Flux values, but nothing yet flattens one stream of data into another. In this step, you implement a flatMap-based pipeline that turns an industry code into an Industry containing its stock quotes, then implement manual backpressure with a custom Subscriber that requests items in bounded batches instead of all at once. By the end of this step, you'll have composed a pipeline and learned to control its demand directly.

4. Challenge

   Step 4: Test the reactive endpoints

   Your pipeline and endpoints work, but so far you've only trusted them by eye. Reactive types like Mono and Flux don't behave like plain return values under a normal assertion, so in this step you write your own tests with the tools built for reactive code: WebTestClient for your controller and StepVerifier for your pipeline. By the end of this step, you'll have a repeatable way to prove both pieces keep working as you change them.

5. Challenge

   Step 5: Stream live updates with server-sent events

   This step has you expose a new endpoint that pushes data to a client over time instead of returning it all at once, using Reactor's Flux.interval and Spring WebFlux's Server-Sent Events support. By the end of this step, a client connected to your API receives updates one at a time as they're produced.

6. Challenge

   Step 6: Compare reactive streams to virtual threads

   Your application is now fully reactive end to end, from single-value responses through a flat-mapped, backpressure-aware pipeline to a live SSE stream. This step has you isolate one deliberately blocking, legacy-style call onto a virtual thread instead of the reactive event loop, then run your finished application so you can see every endpoint working together. By the end of this step, you'll have hands-on experience with virtual threads as a complementary tool alongside Project Reactor, and a running application you built yourself.

7. Challenge

   Step 7: See the Impact: blocking vs. reactive under load

   Your application is running and you've confirmed each piece works on its own, but the actual payoff of everything you've built has stayed conceptual so far. This step gives you a direct, measurable comparison: a small pre-built blocking server using the same thread-per-request model your reactive app replaced, running alongside the application you built. You'll send the same burst of concurrent requests to both and time the difference yourself. By the end of this step, you'll have a concrete, felt number for why reactive programming matters under load, not just a diagram of it.