Manuel Bernhardt

Manuel Bernhardt
Manuel Bernhardt is a passionate engineer, author, speaker and consultant who has a keen interest in the science of building and operating networked applications that run smoothly despite their distributed nature. Since 2008, he has guided and trained enterprise teams on the transformation to distributed computing. In recent years he is focusing primarily on production systems that embrace the reactive application architecture, using Scala, Play Framework and Akka to this end. Manuel likes to travel and is a frequent speaker at international conferences. He lives in Vienna where he is a co-organizer of the Scala Vienna User Group. Next to thinking, talking about and fiddling with computers he likes to spend time with his family, run, scuba-dive and read. You can find out more about Manuel's recent work at


All Posts by this author

Akka Typed is back for round 4!

Tour of Akka Typed: Event Sourcing

Manuel Bernhardt continues his series about Akka Typed, the new Akka Actor API that brings significant advantages over the classic one. In his fourth entry, he takes a closer look at one of the most popular use-cases for Akka: event sourcing.

It's time for part 3 of the Akka Typed series

Tour of Akka Typed: supervision and signals

Manuel Bernhardt is back for part three of his series about Akka Typed, the new Akka Actor API that brings significant advantages over the classic one. In his third entry, he looks at one of the core concepts of actor systems: supervision and failure recovery.

Let's build a payment processor with Akka Typed

Tour of Akka Typed: Protocols and Behaviors

Manuel Bernhardt starts a new series about Akka Typed, the new Akka Actor API that brings significant advantages over the classic one. This first entry gets started by easing into the topic to show us a little bit of what it’s capable of. He talks about how to build a payment processor making the most of Akka Typed.

There's never too much of a good thing

Akka anti-patterns: Too many actors

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.

You sure you've been doing it the right way?

Akka anti-patterns: Java serialization

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.

Useful or not?

Akka anti-patterns: Stateless actors

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.

Pick the right Scala library for your project

A quick tour of build tools in Scala

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.


A tour of Akka cluster – Cluster sharding

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.

Let's go exploring!

A tour of Akka Cluster – Akka distributed data

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.

Akka anti-patterns: being out of touch with the hardware

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.

Why running 1000+ actor systems on one JVM is a bad idea

Akka anti-patterns: too many actor systems

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.

Beware of missteps

Akka anti-patterns: data races

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.

  • 1
  • 2