What Does It Mean to Be 'Reactive?'

Reactive Serving

Let’s imagine that you just became the owner of a little restaurant that only has a few tables (three, for example), and you have to hire an entire staff. What are your choices? Assuming that you only need one chef, how many waiters do you need to hire?

Approach 1

In this first approach, let’s try to solve this problem by using a classic (non-reactive) execution environment that only sponsors one-thread-per-request. Take a look below:

This solution looks interesting, especially if we want to suggest our restaurant as a local favorite, but meanwhile, we have to take into consideration the costs (number of waiters) and the fact that, the majority of the time, waiters do nothing.

On a scalability note, it is easy to understand that if you want an increasing number of tables in your restaurant, you have a linear increase in cost and resource needed.

Let's take a step back from this metaphor. By substituting the waiters with threads, the chef possesses the processing capability and the customer requests that we obtain. This includes what happened inside a classic execution environment where each thread is dedicated to a single request.

Approach 2

Now, let’s try to solve this problem using a different approach to the reactive execution environments that sponsor the single-thread-event-loop. Take a look below:

In the image above, we demonstrate one waiter for all customers — one thread for all requests. This approach assumes that we have one “reactive” waiter that works hard and asynchronously to satisfy the need of all customers interacting with the chef.

This solution probably looks less fascinating from the previous one, but it is absolutely more efficient because it contains lower costs and uses the maximum capability of your waiter. Therefore:

The more “reactive” the waiter and chef … the more effective your service is!

A quick note on scalability: if you want to increase the number of tables in your restaurant, you have to understand how reactive your waiter is, and if you need another one, you’ll need search for another reactive waiter. This means that the required costs and resources depend on your ability to manage such issues.

Now, let's take a step away from the restaurant metaphor. While thread plays the role of the waiter — the processing capability of the chef and customer of the request—, you (as owner) play the role of the system resource manager

Conclusion

The question is, in your case, which service model will you choose for your restaurant? Approach 1 or 2?

I hope that metaphor helps you understand how the reactive framework deals with asynchronous execution and the threads.

While a non-reactive system tries to manage resources using a predictive model (max number of threads, max number of requests per time), the reactive system relies on system capacity involving fewer resources that are better used, making the overall throughput of the system unpredictable (for that, we have to use empiric approach).

Enjoy the reactive world!!