Reactive Programming for 20,000+ RPS Parallel Processing: Insights from a Naver Interviewer
This course is for developers who want to find fundamental solutions in environments where response times slow down as traffic increases, thread pools are quickly exhausted, and bottlenecks worsen with more external API calls. It helps you look at problems from the perspective of changing the architecture itself, rather than simply scaling out servers.
Through this course, you will first understand the limitations of the traditional Spring MVC "Thread per Request" model. You will examine at the code level why throughput doesn't increase even when CPU resources are available, and exactly how blocking I/O occupies system resources.
Next, you will learn the concepts and standard specifications of Reactive Streams and master how to handle data streams using Reactor's Mono and Flux. Beyond simple usage, you will learn through hands-on practice how data flows start, how they are consumed, and how throughput is controlled. In particular, you will directly implement design patterns that prevent OOM (Out of Memory) or overloads using Back Pressure.
Additionally, you will understand the event loop-based processing structure of Spring WebFlux and conduct comparative exercises on how Non-Blocking I/O operates during actual request processing. By placing MVC and WebFlux side-by-side to verify their structural differences, you will also establish criteria for when to choose Reactive.
This goes beyond simply "learning asynchrony." You will learn how to handle more requests with fewer threads, how to maintain a stable flow in environments with high external API dependencies, and develop the design intuition to secure throughput in high-concurrency environments.
I took the course "Reactive Programming for 20,000+ RPS Parallel Processing," taught by a Naver interviewer, to broaden my understanding of server architecture and real-time processing methods while working on the SSAFY corporate collaboration project.
In my current project, there were many situations where I had to consider concurrency and response processing structures, such as AI server integration, real-time data processing, and external API communication. At a point where I was curious about the limitations of the existing Spring MVC-based structure, this course was a great help in understanding the overall flow of Reactive programming and WebFlux.
In particular, it was easy to understand because the differences between the Thread-per-Request structure and the Event Loop-based structure, data stream processing using Mono and Flux, and the concept of overload control through Back Pressure were explained with hands-on practice rather than just simple theory. Previously, I thought of WebFlux as just an "asynchronous framework," but through this lecture, I was able to experience firsthand that it is a structural approach to handling high concurrency with fewer resources.
Although I haven't introduced WebFlux to my current corporate collaboration project immediately, the concepts I learned in this lecture were very helpful in the process of considering communication with AI servers and real-time functional structures. In particular, my perspective on the difference between blocking I/O and non-blocking processing, and the bottleneck issues that can occur when there are many external API calls, seems to have broadened compared to before.
Furthermore, it was an experience beyond simple syntax learning as it covered practical considerations such as SSE, WebSocket, Retry patterns, and error handling flows.
I felt that I would definitely like to consider actually adopting WebFlux and Reactive structures in environments where the project scale grows larger or where high concurrency processing and external integrations increase in the future. It was a lecture that allowed me to gain criteria for judging when to appropriately choose Reactive programming, rather than approaching it as just a trendy technology.
5.0
goldrex123
100% enrolled
This is a course where you can learn about WebFlux in general :)
What you will gain after the course
How to design and implement a Spring WebFlux-based non-blocking server from scratch
Ability to design and control data streams using Mono and Flux
Architectural design capability to prevent overload by applying back pressure
The ability to explain the structural differences between MVC and WebFlux and provide criteria for selection.
Architecture design techniques for handling high concurrency with few threads
The ability to identify and resolve issues that arise when mixing blocking and reactive code
Development · Programming · Backend
Change the structure instead of adding more servers Reactive programming where threads never block không làm tắc nghẽn luồng (thread)
This course is a hands-on lecture that goes beyond defining Reactive as just "asynchronous" and instead treats it as a structure for processing more requests with the same resources. The goal is to build a structure that can handle over 20,000 requests per second without increasing the number of threads. It starts with Reactive Streams and Back Pressure, moves into directly using Reactor's Mono and Flux, and extends to practical patterns based on Spring WebFlux.
Difficulty: Beginner
Practice-oriented
Java 17 · Spring Boot
Unlimited access period
Thread per Request → Event LoopA perspective that changes the structure itself
From concepts to practical patternsalmost the entire time is dedicated to hands-on practice
Mono · Flux · Back PressureVerify through code, not just concepts
Curriculum co-designed by a current 10-year veteran server developer at Naver While the difficulty level is introductory, the practical patterns in sections 5 and 6 offer new insights even for those already using WebFlux Practice environment: macOS (Apple M3) · Java 17 · Docker
Spring WebFlux · Non-blocking Reactive Web FrameworkReactive Streams SpecificationBack Pressure to prevent OOMStructural differences between Spring MVC vs WebFluxReactor · Implementation created by the Spring teamMono publishing 0~1 itemsFlux publishing 0 or more itemsEvent Loop based processingHigh Concurrency with fewer threadsParallel Processing · Resolving external API call bottlenecksJava 17 · Spring · Spring BootSpring WebFlux · Non-blocking Reactive Web FrameworkReactive Streams SpecificationBack Pressure to prevent OOMStructural differences between Spring MVC vs WebFluxReactor · Implementation created by the Spring teamMono publishing 0~1 itemsFlux publishing 0 or more itemsEvent Loop based processingHigh Concurrency with fewer threadsParallel Processing · Resolving external API call bottlenecksJava 17 · Spring · Spring Boot
Why this course was started
It all started with a complaint that all the threads were getting blocked.
Below is an actual conversation. It is a dialogue between a Toss developer whose traffic is exploding and a Naver developer who has tried migrating some services to WebFlux.
Toss DeveloperTraffic is exploding lately... The CPU is fine, but the threads can't handle it and are all getting blocked T_T
HongWhat kind of architecture does Toss use? Is it processing with a Thread per Request structure?
Toss DeveloperYeah… Most of it is MVC-based, so when external API calls increase, bottlenecks occur due to blocking sections. It feels like the fundamental issue isn't resolved even if we scale up the infrastructure.
Ande (Naver)To be honest, that's why I'm not a big fan of it. The pros and cons are clear... but I don't think anything can beat Reactive in terms of throughput. Of course, the learning curve is a bit steep, though. ㅠ
Ande (Naver)That's why I switched some services to a WebFlux-based reactive architecture. I only converted a portion to non-blocking, but even then, the throughput scaled very well using the same resources.
Ande (Naver)Just knowing Mono and Flux doesn't solve everything. I think we should at least consider things like the event loop, backpressure, and the mixing of blocking code.
HongAh.... I'm in trouble now lol. This isn't what I intended;;
Toss DeveloperI'd love that lol Highly recommended!!! I'll take a listen too
That is how this course was created. The curriculum was built exactly from the points highlighted by someone who actually performed the migration, focusing on "what you absolutely need to know."
“
From a throughput perspective, nothing can beat Reactive.
Current NAVER Headquarters Server Developer10 years of experience · Personally migrated several services to WebFlux
What you are currently experiencing
Is it enough for a backend developer to be proficient only in synchronous methods?
It's a relief if everything is running smoothly based on traditional Spring MVC. However, once traffic starts to increase, the following issues will occur in order.
As external API calls increase, responses are becoming slower.
The CPU is idle, but the thread pool is quickly exhausted
Traffic is increasing, but infrastructure costs are rising along with it.
The code starts getting more complex when trying to switch to asynchronous.
There is a difference between barely holding on by increasing the number of servers and handling more traffic with the same resources.
Why Spring WebFlux
What makes Spring WebFlux different?
Spring WebFlux is a non-blocking based reactive web framework. While the traditional Spring MVC follows a Thread-per-Request model that assigns a thread to each request, WebFlux operates on an event loop-based architecture. It can be used directly on top of Java and Spring Boot.
Non-Blocking I/O
WebFlux는 요청을 처리하는 동안 스레드를 붙잡지 않아, 적은 스레드로도 높은 동시성을 감당합니다.
Back Pressure
WebFlux는 리액티브 스트림 표준을 따라, 데이터를 만드는 쪽과 쓰는 쪽의 속도를 맞춰 과부하를 막습니다.
Event Loop
WebFlux는 요청마다 스레드를 배정하지 않고 이벤트 루프로 처리해, 동시 요청이 많은 환경에서 유리합니다.
High Concurrency
WebFlux는 외부 API 호출이나 DB I/O처럼 기다리는 시간이 긴 작업에서 스레드를 막지 않아 고트래픽에 강합니다.
Mono · Flux
Reactor의 Mono는 0~1개, Flux는 0개 이상의 데이터를 발행하는 타입입니다. 병렬 처리의 출발점이 이 둘입니다.
Functional
WebFlux는 Spring MVC와 비슷한 애노테이션 방식은 물론, RouterFunction을 활용한 함수형 구성도 지원합니다.
The official documentation describes Spring WebFlux as follows.
The reactive-stack web framework, Spring WebFlux, was added later in version 5.0. It is fully non-blocking, supports Reactive Streams back pressure, and runs on such servers as Netty, and Servlet containers.
Spring WebFlux, a reactive-stack web framework, was added in version 5.0. It is fully non-blocking, supports Reactive Streams back pressure, and runs on servers like Netty as well as traditional Servlet containers. spring-webmvc and spring-webflux coexist side by side within the Spring Framework and can be used together if necessary.
There are things to check before scaling up the infrastructure.
It starts with what reactive is and leads all the way to WebFlux practical patterns.
I have brought the server developer job postings exactly as they are. Requirements include experience with high-volume traffic and asynchronous/non-blocking processing.
TossServer Developer JD
Toss PaymentsServer Developer JD
Daou Kiwoom GroupServer Developer JD
Hecto GroupServer Developer JD
Features of this course
Why this Reactive programming course?
It is based on the experience of transitioning within the Naver platform environment.
This is not a lecture that simply lists WebFlux syntax. It starts by explaining the background—what problems were encountered in environments with high traffic and heavy external API dependencies, and why the Reactive architecture was chosen.
Almost all of the time is dedicated to hands-on practice.
You can't get a feel for Reactive through theory alone. You truly understand it only after seeing the operational flow of Mono and Flux, non-blocking processing methods, and the event loop structure through actual code.
Explain through the structural differences with MVC
"Asynchronous" is not enough as a single word. We compare the limitations of the Thread per Request model, the bottlenecks created by blocking sections, and how non-blocking architectures operate side-by-side.
Broadening the perspective for juniors, providing decision criteria for seniors
WebFlux is not just a trendy technology, but one of the options for high-concurrency environments. We cover both when to choose it and when not to.
What you will achieve after the course
What can I do after completing this course?
The following five items are things you will be able to implement in code or explain with supporting evidence in an interview after completing this course.
Judgment
지금 겪는 병목이 스레드 대기 때문인지 CPU 때문인지 구분하고, WebFlux가 답인 상황인지 아닌지 고를 수 있습니다.
Implementation
Mono와 Flux로 단건·다건 흐름을 표현하고, 연산자를 조합해 여러 외부 호출을 병렬로 묶을 수 있습니다.
Flow Control
생산 속도가 소비 속도를 앞지를 때 Back Pressure로 조절해 메모리가 터지는 상황을 막을 수 있습니다.
Risk Aversion
리액티브 체인 안에 블로킹 코드가 섞였을 때 왜 위험한지 설명하고, 그 지점을 찾아낼 수 있습니다.
Transition
기존 MVC 프로젝트 전체를 갈아엎지 않고 필요한 구간만 논블로킹으로 바꾸는 방식을 설계할 수 있습니다.
Recommended for these people
Who is this Reactive programming course for?
Backend developers who are anxious about thread pool exhaustion as traffic increases
Spring developers who feel the limitations of the MVC architecture but haven't found an alternative
Developers who want to adopt Reactive programming but haven't even been able to try because the concepts feel too vague.
A developer on a team where the cost burden is increasing because they solve problems only through infrastructure expansion
Platform developers struggling with communication delays between services in an MSA environment
A developer who feels a thirst for career growth due to a lack of experience in designing high-concurrency environments
Conversely, if you can immediately explain where Back Pressure operates, why mixing in blocking code is dangerous, and how to choose between MVC and WebFlux, then you do not need this lecture.
Curriculum
Reactive Programming Course Curriculum
It is organized in a sequence for developers learning Reactive for the first time. It starts with concepts and specifications, followed by Reactor basics, operators, practical patterns, and Spring Boot-based applications.
Section 1. Course Introduction
Course Introduction
Spring Reactive & Spring WebFlux
Section 2. Everything About Reactive Programming
What exactly is Reactive Programming?
Reactive Streams specifications standardized and used within the Java ecosystem
The effect of Back Pressure for preventing OOM in data stream structures
Differences and precautions between Spring MVC and Spring WebFlux
Section 3. Fundamentals for Using WebFlux Reactor
Introduction and practice of Reactor created by the Spring Framework team
Basic and core usage of Reactor Mono, which emits 0 to 1 data items
The rest of the basics, including Flux, which emits zero or more data items
Section 4. Various Operators of WebFlux Reactor
We will cover operators for transforming, combining, and filtering data through hands-on practice.
Section 5. Optional Practical Patterns in WebFlux
It covers exceptional situations encountered in practice and their corresponding response patterns.
Section 6. WebFlux Utilization Patterns Based on Spring Boot
We conclude with patterns for actually configuring WebFlux on top of Spring Boot.
Technologies Covered · Practice Environment
What will be used for the hands-on practice?
webflux
Reactor
Mono · Flux
Back Pressure
Reactive Streams
Event Loop
Parallel Processing
Java
Spring
Spring Boot
Docker
macOS (Apple M3)
The course is conducted using Java 17.0.12 LTS on an Apple M3 Air environment, and Docker (28.0.0) is used to set up the surrounding environment when necessary.
If you have finished looking through the curriculum
The course period is unlimited. You can revisit only the sections you need whenever necessary.
This course was co-created by Hong, a platform server developer in Pangyo, and Ande, a 10-year veteran server developer at Naver headquarters.
Knowledge Sharer · Pangyo Platform Server Development
Hong
I am in charge of platform server development in Pangyo. I continue to work as a knowledge sharer to share the methods I studied myself and the problems and solutions I encounter in practice. I don't create these lectures alone; I develop them together with various developers currently working in the industry.
I am a backend server developer with 10 years of experience. I created this course because I wanted to share the technologies and stacks I know with others, and I hope to help you avoid the mistakes I made. I joined this project at the recommendation of a Kakao interviewer and filmed it under Hong's leadership. Please feel free to ask questions, and I will check and answer them as much as possible.
[現] Naver Headquarters Server Developer
[前] Backend Developer at Shinsegae Group
[Former] Healthcare startup server developer
[Former] Majored in Computer Science at a 4-year university in Seoul
It is a method of viewing data as a flow (stream) and processing it without blocking threads when that flow comes in. In the Java ecosystem, there is a standard specification called Reactive Streams; Reactor is the implementation from the Spring camp, and Spring WebFlux is the web framework built on top of it. Section 2 will first cover the concepts and specifications.
Is reactive programming the same as asynchronous programming?
They are not the same. Asynchrony is a broad concept of proceeding with other tasks without waiting for a result, whereas reactive programming is a programming model that treats that asynchronous flow as a data stream and adjusts the production rate to match the consumption rate. The reason this course says the word "asynchronous" alone is insufficient is precisely because of this Back Pressure part.
What is the difference between Spring MVC and Spring WebFlux?
MVC follows a Thread per Request model where one thread is assigned to each request, so if there are long waiting periods like external API calls, threads get tied up and create bottlenecks. WebFlux is event-loop based and non-blocking, so it releases the thread while waiting. The differences and precautions are covered together in the final lecture of Section 2.
What are Mono and Flux respectively?
Both are data publishing types provided by Reactor. Mono publishes 0 or 1 item, while Flux publishes 0 or more items. Single-item lookups are represented by Mono, and lists or streams are represented by Flux. Section 3 covers the basics and core usage of each through hands-on practice.
Why is Back Pressure necessary?
If the producer creates data faster than the consumer can process it, unprocessed data can accumulate in memory, leading to an OOM (Out of Memory) error. Back Pressure is a mechanism that regulates the flow, ensuring the consumer only requests as much as it can handle. This is covered in Section 2 from the perspective of preventing OOM.
Does using WebFlux always make things faster?
No. WebFlux has its strengths in situations where threads are tied up due to frequent external API calls or I/O waits. If the bottleneck is a CPU-intensive operation, changing the structure won't make a big difference, and if blocking code is mixed in, it can actually be detrimental. This course also covers the criteria for making that judgment.
Do I have to convert the entire existing MVC project to WebFlux?
You don't need to change everything. spring-webmvc and spring-webflux coexist side-by-side within the Spring Framework, and it is possible to switch only the necessary services to non-blocking. In fact, the instructor has included their own experience in this course, where they increased throughput using the same resources by converting only specific services.
Can beginners to Reactive follow along?
Yes. As an introductory level course, it starts with what reactive is and the stream specification, then progresses through Reactor basics, operators, and practical patterns. Experience with Java and Spring Boot is sufficient, and the practical patterns at the end will offer new insights even for those already using WebFlux.
How is the practice environment configured?
The course is conducted on an Apple M3 Air using Java 17.0.12 LTS, and surrounding environments are set up using Docker 28.0.0 when necessary. You can complete all hands-on exercises locally without any separate paid cloud subscriptions.
What is the sequence of the Reactive programming course curriculum?
It starts with reactive concepts, Reactive Streams specifications, Back Pressure, and the differences from MVC, followed by Reactor basics (Mono·Flux), various operators, practical patterns, and the use of Spring Boot-based WebFlux. The enrollment period is unlimited.
Instead of increasing threads, we design the flow.
Starting with what reactive is, you will verify everything from Mono·Flux to practical patterns through hands-on practice.
I am running a developer open chat room where we share career advice, real-world scenarios, and technical knowledge. Please feel free to share any questions you have while taking the course or any concerns you face in your actual work.
I started studying development after becoming interested in it while idling at home, and I am currently responsible for platform server development in Pangyo. I am continuing my activities as a knowledge sharer because I want to provide you with the methods I used to study, as well as the various problems and solutions you may encounter in practice.
These lectures are not created solely through my own knowledge. There are others who collaborate on every lecture.
I was deeply impressed by this. Even as a developer in my 6th year in the industry, this lecture makes me realize how much I still have to learn. It was great content that delved into the core essentials despite being a simple topic. Thank you.
I took the course "Reactive Programming for 20,000+ RPS Parallel Processing," taught by a Naver interviewer, to broaden my understanding of server architecture and real-time processing methods while working on the SSAFY corporate collaboration project.
In my current project, there were many situations where I had to consider concurrency and response processing structures, such as AI server integration, real-time data processing, and external API communication. At a point where I was curious about the limitations of the existing Spring MVC-based structure, this course was a great help in understanding the overall flow of Reactive programming and WebFlux.
In particular, it was easy to understand because the differences between the Thread-per-Request structure and the Event Loop-based structure, data stream processing using Mono and Flux, and the concept of overload control through Back Pressure were explained with hands-on practice rather than just simple theory. Previously, I thought of WebFlux as just an "asynchronous framework," but through this lecture, I was able to experience firsthand that it is a structural approach to handling high concurrency with fewer resources.
Although I haven't introduced WebFlux to my current corporate collaboration project immediately, the concepts I learned in this lecture were very helpful in the process of considering communication with AI servers and real-time functional structures. In particular, my perspective on the difference between blocking I/O and non-blocking processing, and the bottleneck issues that can occur when there are many external API calls, seems to have broadened compared to before.
Furthermore, it was an experience beyond simple syntax learning as it covered practical considerations such as SSE, WebSocket, Retry patterns, and error handling flows.
I felt that I would definitely like to consider actually adopting WebFlux and Reactive structures in environments where the project scale grows larger or where high concurrency processing and external integrations increase in the future. It was a lecture that allowed me to gain criteria for judging when to appropriately choose Reactive programming, rather than approaching it as just a trendy technology.
Hello Sunghoon, I am truly, deeply moved ㅠㅠㅠㅠ Reading this gave me so much strength and became the driving force for me to move forward ㅠㅠ I will continue to provide even more informative lectures and strive to satisfy you in the next course as well.
Have a wonderful day today!!!