Tomcat vs Jetty vs Undertow — When to Switch

Q: Tomcat vs Jetty vs Undertow — When to Switch

**Don't switch without a measured reason**. Tomcat is the default because it handles most workloads well and has the broadest tooling and documentation. Switch to **Undertow** when measured `tomcat.threads.busy` saturation is the bottleneck and the workload is heavily I/O-bound. Switch to **Jetty** when you need many idle long-lived connections (WebSocket chat, SSE) or memory footprint at low traffic matters. Switch to **Netty + WebFlux** when the architecture is genuinely reactive and you can avoid blocking calls. **Never benchmark the server in isolation** — the application logic, downstream latencies, and JVM tuning dominate any server-level differences in real workloads.

Intermediate·2 min read·

NetflixDoorDashUberStripeDatadog

Fast recall

Quick revision

Core answer

Don't switch without a measured reason. Tomcat is the default because it handles most workloads well and has the broadest tooling and documentation. Switch to Undertow when measured tomcat.threads.busy saturation is the bottleneck and the workload is heavily I/O-bound. Switch to Jetty when you need many idle long-lived connections (WebSocket chat, SSE) or memory footprint at low traffic matters. Switch to Netty + WebFlux when the architecture is genuinely reactive and you can avoid blocking calls. Never benchmark the server in isolation — the application logic, downstream latencies, and JVM tuning dominate any server-level differences in real workloads.

Interview-ready guide

Interview answer

The honest answer is: don't switch without a measured reason. Tomcat is the default for a reason — it handles most workloads well, has the broadest tooling, and is what most teams already debug confidently.

The diagnostic path before any switch

Confirm saturation, not application slowness — look at tomcat.threads.busy vs threads.config.max
Trace request latency end-to-end — slow downstream calls don't get faster with a different web server
Tune Tomcat first — increase threads.max, raise accept-count, adjust connection-timeout
Move blocking work to @Async — often eliminates the apparent need to switch

When the switch is genuinely justified

Undertow when servlet throughput is the bottleneck and tuning didn't help
Jetty when you have many idle long-lived connections (WebSocket, SSE) or need lower idle memory
Netty + WebFlux when the architecture is genuinely reactive — and you can avoid blocking JDBC, blocking JMS, blocking HTTP clients

The mistakes to avoid

Switching based on a synthetic benchmark — production behavior is dominated by application logic and downstream services
Mixing blocking calls into a Netty reactive stack — worse than Tomcat, not better
Forgetting that server.tomcat.* properties silently no-op after a switch — re-audit configuration

In an interview, the strongest answer is: I'd default to Tomcat, instrument with Actuator and tracing, and only consider a server change after the diagnostic path points clearly to the I/O model as the bottleneck. The server is rarely the bottleneck.

03 · Deep dive