Chapter 1. Why reactive?
Figure 1.1. Reactive systems: responsive, resilient, elastic, message-driven
Figure 1.2. Actors communicate much like people with mobile phones do.
Chapter 2. Reactive application design
Figure 2.1. Creating one actor per shopping cart allows each shopping cart to be accessed independently of the others. This means there’s no contention for resources between User 1 and User 2.
Figure 2.2. The use of state machines with actors in Akka.NET allows you to simplify the process of developing actors with complex internal logic.
Figure 2.3. Creating child actors allows you to perform dangerous work by isolating it from the rest of the application.
Figure 2.4. Sending messages between actors is a fundamental part of reactive application design.
Figure 2.5. You can parallelize stateless operations by using multiple actors behind a routing proxy.
Figure 2.6. A simple e-commerce checkout flow has a number of interconnected components that can be built from the design patterns you’ve seen so far.
Figure 2.7. Akka.NET applications need to be accessible to a number of clients. This can be achieved through the use of a web proxy in front of the application.
Chapter 3. Your first Akka.NET application
Figure 3.1. An actor embodies communication, processing, and state.
Figure 3.2. An example actor hierarchy in an Akka.NET application
Figure 3.3. The four parts of an actor address