anchor.diff:  Performance has many characteristics and meanings. Reactive and non-blocking generally
   do not make applications run faster. They can, in some cases, (for example, if using the
   `WebClient` to execute remote calls in parallel). On the whole, it requires more work to do
  -things the non-blocking way and that can increase slightly the required processing time.
  +things the non-blocking way and that can slightly increase the required processing time.
   
   The key expected benefit of reactive and non-blocking is the ability to scale with a small,
   fixed number of threads and less memory. That makes applications more resilient under load,
  
positive.code: difference in the concurrency model and the default assumptions for blocking and threads.
  
  In Spring MVC (and servlet applications in general), it is assumed that applications can
  block the current thread, (for example, for remote calls), and, for this reason, servlet containers
  use a large thread pool to absorb potential blocking during request handling.
  
  In Spring WebFlux (and non-blocking servers in general), it is assumed that applications
  do not block, and, therefore, non-blocking servers use  a small, fixed-size thread pool
  (event loop workers) to handle requests.
  
  TIP: "`To scale`" and "`small number of threads`" may sound contradictory but to never block the
  
negative.code: the way they are used is very different. Spring MVC relies on Servlet blocking I/O and
  lets applications use the Servlet API directly if they need to. Spring WebFlux
  relies on Servlet 3.1 non-blocking I/O and uses the Servlet API behind a low-level
  adapter. It is not exposed for direct use.
  
  For Undertow, Spring WebFlux uses Undertow APIs directly without the Servlet API.
  
  