فهم الأساس التفاعلي

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.

What underlying web stack does Spring Cloud Gateway run on?

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.