Dante
Dante

Reputation: 3891

Granularity of actors in actor model

My team is debating how granular our actors should be.

As an example, we have an actor that is responsible for deserializing a json string into an object. The argument in favour of making it an actor is that the deserialization can cause errors and actors and their supervision model can be used for control flow.

Is it a good idea to use actors for this and other small tasks?

Upvotes: 1

Views: 429

Answers (1)

Patrick Allwood
Patrick Allwood

Reputation: 1832

Yes, it is a good idea to delegate tasks that are routinely prone to failure to child actors which handle that specific task. This pattern is referred to as the Character Actor pattern on the Petabridge blog, but reiterated below in case the link breaks in future.

The Character Actor Pattern is used when an application has some risky but critical operation to execute, but needs to protect critical state contained in other actors and ensure that there are no negative side effects.

It’s often cheaper, faster, and more reliable to simply delegate these risky operations to a purpose-built, but trivially disposable actor whose only job is to carry out the operation successfully or die trying.

These brave, disposable actors are Character Actors.

Character actors can be temporary or long-running actors, but typically they’re designed to carry out only one specific type of risky operation. Often times character actors can be re-used throughout an application, belonging to many different types of parents. For example, you may have a utility character actor that handles making external network requests, and is then used by parent actors throughout your application for their own purposes.

Use Cases

The Character Actor pattern is broadly applicable. Use it any time you need to do something risky such as network calls, file I/O, parsing malformed content, and so on. Any of these operations is a good candidate for a character actor.

Character actors are most effective when used to provide protection and fault isolation to some other important type of actor, typically one containing some important state.

Benefits

There are three key benefits to using the Character Actor Pattern:

  • Insulates stateful and critical actors from failures and risky operations;
  • Makes it easy to cleanly introduce retry / backoff / undo semantics specific to each type of risky operation: since you have a character actor specific to each risky task, you have a well-defined place to put retry handling and related operations. These are specific to the task the Character Actor was created for and don’t need to be shared with the rest of your actors, meaning that the pattern…
  • Reduces code by letting the SupervisionStrategy and actor lifecycle do most of the heavy lifting, you don’t need all sorts of exception handling code in your parent actors. Just let it crash, baby.

Upvotes: 2

Related Questions