spring-cloud
Clarification on HTTP-Based Streaming Support in Spring Cloud Gateway
I'm currently working on a production use case involving Spring Cloud Gateway (SCG) and had a question regarding its support for HTTP-based streaming.
We are using:
Spring Boot: 2.2.9.RELEASE
Spring Cloud Gateway: 2.2.2.RELEASE
In our setup, SCG is configured to route requests to a downstream HTTP service (e.g., http://downstream-service/stream/data) that returns a reactive stream, typically via Flux<T> with the response header "Content-Type: text/event-stream".
My understanding is:
SCG internally uses Spring WebClient with Reactor Netty.
When the downstream responds with a streaming content type like "Content-Type: text/event-stream", SCG does not buffer the full response, and instead streams it reactively and directly to the client.
This behavior is achieved entirely over HTTP, without involving WebSockets.
SCG’s reactive foundation allows this model to scale efficiently, supporting many parallel, long-lived connections — assuming non-blocking behavior throughout the chain.
Could you kindly confirm if this understanding is accurate?
Additionally, assuming the downstream service is reactive and non-blocking as well, could you please share any insights or guidance on how much this model can scale — for example, how many concurrent streaming clients can SCG realistically support under such conditions? Any best practices, system limits, or tuning tips would be greatly appreciated.
If possible, I would also be thankful for any official documentation or internal class references (e.g., GitHub files) that validate this behavior and performance model.
Thank you for your continued work on Spring Cloud Gateway
@manzhizhen I came across your comment on #3039 and noticed a similar behavior in my case. https://github.com/spring-cloud/spring-cloud-gateway/issues/3039#issuecomment-1738633084 If you happen to have any insights or suggestions on this, I'd really appreciate your input. Of course, I completely understand if it's not something you're looking into at the moment.
Thanks in advance!
@manzhizhen I came across your comment on #3039 and noticed a similar behavior in my case. #3039 (comment) If you happen to have any insights or suggestions on this, I'd really appreciate your input. Of course, I completely understand if it's not something you're looking into at the moment.
Thanks in advance!
Sorry, actually I haven't encountered any problem with data fragments not being returned in a timely manner when using SSE on SCG
@manzhizhen I came across your comment on #3039 and noticed a similar behavior in my case. #3039 (comment) If you happen to have any insights or suggestions on this, I'd really appreciate your input. Of course, I completely understand if it's not something you're looking into at the moment. Thanks in advance!
Sorry, actually I haven't encountered any problem with data fragments not being returned in a timely manner when using SSE on SCG Thanks for the reply @manzhizhen. Actually, I'm not encountering issues either — the SSE stream is working fine when tested via curl, and I'm seeing real-time responses. I was mainly trying to understand how SCG handles SSE streaming under the hood — particularly how it maintains the stream and flushes data through the reactive pipeline. Additionally, I'm curious to know: Can SCG efficiently handle a large number of parallel SSE streams in this kind of setup? Any insights or official references on this would be really helpful. If you happen to know of any official resources, documentation, or code references that explain this behavior in Spring Cloud Gateway, I’d love to check them out.