Reactive applications are the "hot new thing", but what should be the criterias/factors a development team should consider using it instead of a traditional blocking application?
That's a tough one to answer, because it's hard to give a blanket statement for all projects, when individual project goals will vary. But...to put it in a general statement...
Reactive, in a nutshell, enables an application to do more with less: Achieve more with fewer threads, rather than a large thread pool. The key difference is that those few threads are super-busy, rather than lots of threads in a pool that are being swapped out (and paying the overhead for that swapping).
So even if a project doesn't really need the benefits of reactive, then there can be some benefits realized. The gotchas, however, might guide you toward avoiding reactive. Specifically...
- A little reactive sprinkled into an otherwise imperative/blocking application won't see too many benefits and possibly might make things worse. You won't realize the full benefits of reactive unless the project is fully reactive.
- There are situations where reactive isn't an option. JDBC/JPA-centric persistence will be block and affect the benefits of reactive upstream. R2DBC and Spring Data R2DBC offer some reactive benefits for certain relational databases, but if that's not your database, then you're out of luck. Mongo, Cassandra, and a few others are great options for non-blocking persistence, but those may or may not be options for you.
- Reactive thinking twists the brain differently than imperative programming. In other words, there's a learning curve and your team will all need to be reactive-minded or else you'll find someone writing some really bad "reactive" code that actually creates blocks. Fortunately, Spring (as much as possible) makes the transition to reactive easy; specifically, I'm thinking of Spring WebFlux vs. Spring MVC where the programming model is nearly identical. But you'll still need to understand how to write reactive code within your controller methods and the backend components that your controller consumes.
But again, there's no general advice I can give. I tend to favor the benefits of reactive, but honestly...I sometimes start off with non-reactive just to get started and then transition as the project matures. (Of course, if you wait too long to make that transition, then you'll have quite a chore on your hands.)