ActorModel — Getting started

Photo by Mika Baumeister on Unsplash

ith the advent of more and more powerful hardware, efficient network, and equally capable software the expectation of the overall business experience from any Platform has dramatically increased. Frameworks like Angular and React have given so much more to the users to work with on the screens and that has attracted an increased focus on the User Interface development more than ever. More and more users would be using the software especially when there is an event or a year-end sale or something of that sort.

What this has done to the system underneath is it has put an additional load on the overall resources supporting the Platform. As an Architect one needs to ensure that the system is not getting into an choked. The platform should remain Available, Scalable especially when the system is experiencing a sudden surge of traffic.

With this backdrop, let’s try and explain the problem that we are going to target in this blog and see what all options we have with us.

The Problem

Often in the circumstances we briefly touched upon above we have seen that systems if not built with these concerns in mind either gets into an inconsistent state or are unable to handle this much load and start deteriorating and become unusable and eventually collapse. If none of this happens then surely these concerns are handled within the Platform, the Architects, Leads, Development teams must have given a thorough thought before deploying the solution. More often than not, handling concurrency has been a challenge, threads compete with each other for the shared resources and they get into a race for updating that and ensuring they are not working on the obsolete state of the resource.

We all know how much it takes to manage concurrency, i.e. managing the consistent state of the shared resources in a multithreaded environment. The threads take a lock on the semaphore, executes their business logic, and release the lock so that other competing threads can get access to the semaphore. Especially when the system is experiencing a tremendous load we can just imagine how many permutations possibly can arise.

Well, we have been talking about the concerns that come along with having a multithreaded environment, is there anything that can be used out of the box and free up the developers to focus on the actual business requirements that they need to work on? The answer is Yes!

Akka to the rescue!

What Akka provides distinctively is that the developers don’t need to worry at all about the multithreading issues anymore. They just need to focus on developing their business logic and Akka takes care of ensuring that the Platform in general remains in a consistent state.

Akka is a framework that vows to make the most of the resources and facilitates the developers in building an application that’s scalable enough to manage literally any workload from big data, applications involving financial transactions at a rapid rate to developing gaming apps, to say the least.

As we have seen above, it is not easy to handle issues with multiple threads without seriously impacting the performance of the underlying platform, with Akka however all these concerns are nicely abstracted from the developers. Now, what are the tricks of the trade that one needs to know, let’s take a quick look at all the building blocks of an Akka system.

Basic Components

Just like every other Framework Akka is no different from being composed of some of the basic building blocks that help its users to make the most use of its capabilities.

1. Actors
   Actors are the basic building blocks of the Akka system. They are the basic unit of work that the overall system is dealing with. It has a state and also encapsulates the behavior. Actors would always be running in a single-threaded environment thereby ensuring that the issues related to concurrency do not creep in at all. Another key point with Actors is they communicate with each other only via messages. What this also means is there’s no scope of directly invoking the behavior of an Actor by anything outside of an Actor. Another point worth noticing with respect to Actors is that they work on immutable messages. While they are not processing any message they remain in a dormant mode. The overall architecture while working with the Akka framework tends to be Asynchronous and hence there’s no blocking of threads. Every Actor has a unique address just like any computer on the internet has an IP Address, and all the messages that are sent for an Actor are stored in their mailbox. These messages are then read by the Actor in a FIFO mode and the framework ensures that they are processed once at a time. Refer to Figure#1 for more clarity
2. Actor System
   It is essentially the area where all the bootstrapping happens an application that’s driven by Akka. It provides a place where all configurations go in and it is generally one per application. It provides a platform using which the Actors can be categorized and also provides the support for ensuring smooth communication across Actors. The Actors are designed and implemented with the Single Responsibility Principle in mind and are broken to that extent which ensures the intactness of this fundamental principle.

Figure#1

Fault Tolerance and Exception Handling

How often we have felt the need for a worthy controlling mechanism especially when things go out of control? Akka is no different in this regard. But the good thing with Akka is that there is a sound emphasis given to the core of the framework itself. Yes, that’s right. Let’s find it out.

In Akka an Actor is not an independent entity, i.e. there is a supervisor for every Actor within the Akka system and that is responsible for the life cycle of an Actor. During the course of execution, there happens to be some exception, the very first thing that the Actor does is to inform the supervisor. The supervisor is also just like any other Actor but it knows how to deal with the messages that it receives from its child. When Actor gets into any trouble what it also does is immediately suspend itself and all of its children and inform the parent about this.

From here, the supervisor or the parent Actor needs to take some course of action in order to handle this signal it has got from its child. There are the following options available with the parent Actor

1. Resuming the Child
   In this strategy, the Parent decides to resume the child and its children, the only condition being the error has not corrupted the state of the Actor
2. Restarting the Child
   When the Parent knows that the error might have resulted in the state corruption of the Actor, then it issues a restart signal to the Actor and resets the state of all the children
3. Stopping the Child
   In this, the Parent decides to stop the child Actor as it feels that the error is irrecoverable and resuming and re-starting will not solve it
4. Stopping itself
   In this strategy, the Parent Actor once notified of an error in the child, decides to shut itself down and escalates the error to its Parent. This happens when the Supervisor is unable to handle the kind of error it has received from its child.

Where we should use it

With what we have learned from above it is imperative that we also got a sense of where the framework can be utilized. In general, Akka can be used in areas involving concurrency, i.e. where multiple threads are competing with each other for shared resources. It can be applied to but not limited to the following areas:

1. Transaction handling
2. Gaming and betting Apps
3. Batch processing
4. Data Mining apps