Java / Quarkus Interview questions
What is the difference between Quarkus's Vert.x-based reactive engine and traditional servlet-based engines?
The two models differ in how they map incoming connections to threads, which is the root cause of their different scalability characteristics under high concurrency.
| Traditional Servlet Engine | Vert.x Reactive Engine |
| Typically one thread dedicated per in-flight request. | A small pool of event-loop threads multiplexes many connections. |
| Thread blocks and waits during I/O (DB call, downstream HTTP call). | Non-blocking I/O lets the event loop serve other requests while waiting. |
| Concurrency limited by configured thread pool size. | Concurrency limited mainly by available memory and non-blocking code discipline. |
| Simpler mental model; blocking code is the default and expected. | Requires care to avoid accidentally blocking the event loop. |
Quarkus doesn't force an all-or-nothing choice: it runs blocking request handlers on a worker thread pool exactly like a servlet engine would, while reactive handlers run directly on the Vert.x event loop, so an application can mix both models and only pay the added complexity of the reactive style where its scalability benefit is actually needed.
What typically limits concurrency in a traditional servlet engine?
What must reactive handlers avoid doing to work correctly on the event loop?
More Related questions...
