Chapter 1. Why Reactive?
Figure 1.1. The structure of Reactive values
Figure 1.2. Partially decomposed module hierarchy of the hypothetical Gmail implementation
Chapter 2. A walk-through of the Reactive Manifesto
Figure 2.1. The front-end server for images first checks an in-memory cache, then attempts to retrieve the image from storage, and finally returns a fallback image if neither is successful.
Figure 2.2. Using standard listener threads and a connection pool results in the listeners acting as queue entries, with overflow into the system TCP buffers.
Figure 2.3. Adding an explicit queue to manage access to the database connection pool allows you to manage the maximum system latency separately from the listener thread pool size and the connection pool size.
Figure 2.4. A task consisting of three subtasks that are executed sequentially: the total response latency is given by the sum of the three individual latencies.
Figure 2.5. A task consisting of three subtasks that are executed in parallel: the total response latency is given by the maximum of the three individual latencies.
Figure 2.6. A task consisting of three subtasks that are executed as Futures: the total response latency is given by the maximum of the three individual latencies, and the initiating thread does not need to wait for the responses.
Figure 2.7. Amdahl’s Law specifies the maximum increase in speed that can be achieved by adding additional threads.