TypeSafe's Kevin Webber: Actor-based Concurrency for Reactive Systems
In a recent article on Medium, TypeSafe's Kevin Webber argues that reactive programming "isn’t just another trend but rather the paradigm for modern software developers to learn" since it helps them to build systems that are responsive, resilient, and scalable. He also suggests that actor-based concurrency is the most convenient foundations for a reactive system.
According to reactive manifesto, reactive applications are built on four guiding principles: responsiveness, resiliency, scalability, and message-driven architecture. In Kevin's view, those four guiding principles are closely related in that both resiliency and scalability are necessary qualities to ensure that a system remains responsive, i.e., "quick to react to users," under varying working conditions and loads. A message-driven architecture, furthermore, "provides the overall foundation for a responsive system" by naturally supporting desirable characteristics that a resilient and scalable system should have.
Kevin recalls that three key characteristics of a resilient system that are naturally enforced through a message-driven architecture: isolation, location transparency, and the availability of a dedicated separate error channel. Those factors help "towards incorporating robust error handling and fault tolerance into applications."
When it comes to scalability, Kevin highlights two distinct advantages of a message-driven system: the difficulty "to scale out an application based on shared mutable state, threads, and locks" as it happens in the classical thread-based approach to concurrency; support for system elasticity, which is the capability of "adding new resources to your system on demand as the needs of your system change."
Finally, Kevin describes two different approaches to building a message-driven system: event-driven and actor-based. An event-driven system is based on events and event observers; when an event happens in it is dispatched through some kind of callback system to its observers. In an actor-based system, instead, messages are directed to a recipient, the actor, instead of being anonymous callbacks. An actor has three properties:
- A mailbox for receiving messages.
- The actor’s logic, which relies on pattern matching to determine how to handle each type of message it receives.
- Isolated state — rather than shared state — for storing context between requests.
Actor-based concurrency has two main advantages, according to Kevin: it avoids a phenomenon known as callback hell and makes it even easier to scaling out across network boundaries, since you do not need to think about nested callbacks but only focus on the message flows between actors.
Reactive programming is a topic that InfoQ has already covered extensively in the past. A few recent highlights are: What Every Hipster Should Know About Functional Reactive Programming, End-to-End Reactive Programming at Netflix, Virtual Panel on Reactive Programming.