Manuel Bernhardt’s Akka anti-patterns series continues. This time, he takes a closer look at a very frequent anti-pattern that can be found in codebases written by developers who have just discovered the actor model; and that is to have too many actors. Whilst Akka is entirely capable and designed to run many actors, this isn’t always the best approach.

The Akka documentation discourages the use of Java serialization but performance is just one reason to not use Java serialization – there are stronger reasons to not engage with it, especially in the context of Akka. What to do instead? In this article, Manuel Bernhardt gives some alternatives.

What is the importance of actors and why stateless actors make little sense? In this article, Manuel Bernhardt briefly explains the main purpose of actors and their state.

In such a vast and rich ecosystem such as Scala’s, it is often difficult to decide what is the best library or build tool choice for a certain project. Here, Manuel Bernhardt gives a quick tour of build tools in Scala in order to help you pick the right tool for your project.

The tour of Akka cluster continues! In the previous article, we learned how to use techniques for making a reactive payment processor resilient to failure using Akka Cluster. Here, Manuel Bernhardt takes a closer look at how to scale out the reactive payment processor application using cluster sharding.

Do you want to build a more stable system that’s able to cope with individual node crashes? Join Manuel Bernhardt in this tutorial as he shows us techniques for making a reactive payment processor resilient to failure using Akka Cluster.

How can we make building distributed systems easier? In this article, Manuel Bernhardt explores one useful tool in the Akka toolbox: Akka Cluster. Today, we’re taking a closer look at one module, Akka Distributed Data, and how it can be used to build an example reactive payment processor.

Choosing Akka as a tool is often – if not always – driven by the need for good performance. Surely, the actor model itself is appealing as a means for organizing and reasoning about code, but this isn’t in itself a good reason enough to use the Akka toolkit.

Admittedly I’ve seen this one in use only one time, but it was one time too many. For some reason I keep seeing clients come up with this during design discussions and reviews, therefore it makes it into the list of Akka anti-patterns.

When working with actors, you should always respect the following guideline: Do not, under any circumstances, close over mutable state. Since the actor model is a model, not a framework, it is up to you to make sure that you do, indeed, follow this guideline. Akka will not magically warn you if you misstep; however, your application will begin to act weirdly. In this article, Manuel Bernhardt explores a few ways in which you could misstep.

One of the fundamental ideas built into Akka is the one of failure handling through parental supervision. In other words, this means agencing actors in such a way that parent actors that depend upon the correct execution of a child to perform their work are also responsible for deciding what to do when one child actor crashes.

When I work with clients on designing actor systems there are a few anti-patterns that seem to make it into initial, non-reviewed designs no matter what. In this series of short articles I would like to cover a few of those.

Akka is in many ways a very innovative and yet robust technology. Now that it has become generally accepted that microservice-oriented architectures are a good idea, Akka will play an even more important role in the reactive system at large and already serves as a foundation for other reactive technologies such as the Play Framework and Lagom.