Exercises in Programming Style–Actors

You can become a serverless blackbelt. Enrol to my 4-week online workshop Production-Ready Serverless and gain hands-on experience building something from scratch using serverless technologies. At the end of the workshop, you should have a broader view of the challenges you will face as your serverless architecture matures and expands. You should also have a firm grasp on when serverless is a good fit for your system as well as common pitfalls you need to avoid. Sign up now and get 15% discount with the code yanprs15!

NOTE : read the rest of the series, or check out the source code.

If you enjoy read­ing these exer­cises then please buy Crista’s book to sup­port her work.


Following on from the last post, we will look at the Actors style today.


Style 28 – Actors


  • The larger problem is decomposed into ‘things’ that make sense for the problem domain.
  • Each ‘thing’ has a queue meant for other things to place messages in it.
  • Each ‘thing’ is a capsule of data that exposes only its ability to receive messages via the queue.
  • Each ‘thing’ has its own thread of execution independent of the others.


I have been looking forward to doing this style every since the Letterbox style months ago  So without any delay, let’s get started!

F# has built-in support for the Actor Model via the MailboxProcessor type, and we’ll use it to represent each of the ‘things’ in our solution here.

First, we’ll create an actor to load and store the words that we need to process. Since MailboxProcessor is generic, we can define what messages it can receive with a DataStorageMessage union type that allows two kinds of messages:

  • LoadWords – which contains the path to the local file to load words from
  • NextWord – once loaded, this message fetches the next available word

In the snippet below, you can see that we have a recursive receive loop which asynchronously waits for message to arrive in its mailbox and handles them accordingly. One thing to note here is that, if a LoadWords message is received before all the loaded words are processed the current behaviour is to override the remaining words list. This can give you unexpected results, the current design leaves the responsibility of ensuring this doesn’t happen with higher level abstractions (see the controller actor below).


Next, we’ll add another actor to manage the stop words. Similar to the dataStorageManager, we’ll first define the messages that can be sent to our actor:

  • LoadStopWords – which contains the path to the local file to load stop words from
  • IsStopWord – which passes in a word and expects a boolean as reply

As we did in the dataStorageManager, whenever the stopWordsManager actor receives a LoadStopWords message it’ll replace the current list of stop words. All future words passed in via the IsStopWord message will be checked against the updated list of stop words.


Next, we’ll add an actor to track the word frequencies. This actor can accept three messages:

  • Add – adds another word to the current word frequencies
  • TopN – fetches the current top N words with their corresponding frequencies
  • Reset – resets the count

Again, the code snippet below should be pretty straight forward, although there is actually a frailty here due to the use of Seq.take. One thing that often annoys me about Seq.take is that, unlike Enumerable.Take, it throws when there is insufficient number of elements in the sequence! In this case, if the calling agent ask for TopN too early or with a large N it’s possible to kill our actor (which is also something that we’re not handling here). It’s fine given the context of this exercise, but these are things that you need to consider when writing production-ready code.


Lastly, we’ll add an actor to orchestrate the control flow of our program, that will accept a simple Run message. Here, I’ve added an AsyncReplyChannel<unit> to the Run message so that the caller has a deterministic way to know when the program has completed.

When the controller receives a Run message, it’ll initialize the other actors (which happens concurrently due to the asynchronous nature of messaging) and then process all the words from Pride and Prejudice by recursively fetch words from the dataStorageManager until there’s no more. One thing to note is that, because a MailboxProcessor process messages one-at-a-time, so even if the controller receives multiple Run messages at the same time it’ll still process them one at a time and we don’t even have to use locks!



To run our program, we’ll kick things off by sending a Run message to the controller. I opted to run this synchronously, but you could just easily ignore the reply and run the program asynchronously with Async.Ignore and Async.Start.



I’m a massive fan of Erlang and the Actor Model, they’re highly related since Erlang implements the Actor Model but shouldn’t be mixed up – e.g. code hot swapping and supervision trees are features of Erlang and Erlang OTP, and are not prescribed as part of the Actor Model (which is a theoretical model for describing computation).

If you haven’t already, please go ahead and watch this Channel9 recording of a conversation between Carl Hewitt and Erik Meijer on the Actor Model – what it is, and what it isn’t. I also did a write up to summarise the key points.


You can find the source code for this exercise here.

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.
Subscribe to my newsletter

Hi, I’m Yan. I’m an AWS Serverless Hero and I help companies go faster for less by adopting serverless technologies successfully.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

Hire me.

Skill up your serverless game with this hands-on workshop.

My 4-week Production-Ready Serverless online workshop is back!

This course takes you through building a production-ready serverless web application from testing, deployment, security, all the way through to observability. The motivation for this course is to give you hands-on experience building something with serverless technologies while giving you a broader view of the challenges you will face as the architecture matures and expands.

We will start at the basics and give you a firm introduction to Lambda and all the relevant concepts and service features (including the latest announcements in 2020). And then gradually ramping up and cover a wide array of topics such as API security, testing strategies, CI/CD, secret management, and operational best practices for monitoring and troubleshooting.

If you enrol now you can also get 15% OFF with the promo code “yanprs15”.

Enrol now and SAVE 15%.

Check out my new podcast Real-World Serverless where I talk with engineers who are building amazing things with serverless technologies and discuss the real-world use cases and challenges they face. If you’re interested in what people are actually doing with serverless and what it’s really like to be working with serverless day-to-day, then this is the podcast for you.

Check out my new course, Learn you some Lambda best practice for great good! In this course, you will learn best practices for working with AWS Lambda in terms of performance, cost, security, scalability, resilience and observability. We will also cover latest features from re:Invent 2019 such as Provisioned Concurrency and Lambda Destinations. Enrol now and start learning!

Check out my video course, Complete Guide to AWS Step Functions. In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. There is something for everyone from beginners to more advanced users looking for design patterns and best practices. Enrol now and start learning!