ทำความเข้าใจพื้นฐานแบบรีแอกทีฟ

Unlike a traditional Spring MVC app, Spring Cloud Gateway runs on Spring WebFlux and Project Reactor. It uses a non-blocking, event-loop server (Netty) instead of one thread per request.

This design lets the gateway handle thousands of concurrent connections with very few threads.

In a blocking model, a thread waits idle while a backend responds. In a non-blocking model, the thread is freed and notified later when data is ready.

• Blocking: 1 thread tied up per in-flight request
• Non-blocking: a handful of threads serve many requests

Reactor's core types describe asynchronous results:

• Mono<T> emits 0 or 1 value
• Flux<T> emits 0 to many values

The gateway returns a Mono<Void> when a request finishes processing.

Reactive streams are lazy. A Mono or Flux does nothing until something subscribes. In the gateway, the framework subscribes for you when a request arrives.

The starter spring-cloud-starter-gateway pulls in WebFlux automatically. You must not add spring-boot-starter-web (the servlet/MVC stack) or startup will fail with a conflict.

Every request is wrapped in a ServerWebExchange, which holds the request and response. Filters read and mutate this exchange as the request flows through.

A request passes through an ordered chain. Each filter can act, then call chain.filter(exchange) to continue, and run more logic after the downstream response returns.

A gateway spends most of its time waiting on the network for upstream services. Non-blocking I/O is ideal here: threads are not wasted waiting, so the gateway stays responsive under heavy load.

Calling a blocking JDBC driver or Thread.sleep inside a filter stalls the event loop and hurts every request. If you must block, offload to a bounded scheduler.

Operators like map, flatMap, and filter reshape the data flowing through a stream without blocking.

Think of the gateway as a pipeline of asynchronous steps. A request enters, flows through predicates and filters, is forwarded reactively, and the response streams back through the same chain in reverse.

You now understand the reactive foundation of the gateway:

• Non-blocking I/O on Netty handles high concurrency
• Mono and Flux model async results and are lazy
• Each request is a ServerWebExchange flowing through a filter chain
• Never block the event loop

This mindset underpins routes, predicates, and filters you build next.