Design patterns/best practice for building Actor-based system
I am struggling to find any decent links to design patterns, best practice or good, basic architectural principles that should be used in building Actor-based apps. Those few that I know of are:
Blog posts, articles, WIKIs, guides
- OTP Design Principles User's Guide
- Patterns and Best Practices for Enterprise Integration (in general, can be applied to any message-driven architecture)
- Series of posts by James Iry on dealing with state in design with actors
- Series of posts on design with Scala actors by Ittay Dror
- Concurrency patterns article on wikipedia
- Scalable System Design Patterns (not directly related to actors, but quite useful)
- Understanding actor concurrency, pt.1, pt.2 by Alex Miller
Papers
- Disseration on making reliable distributed systems by Joe Armstrong
- Scalabale Component Abstractions by Philipp Haller and Martin Odersky
- Event-based programming without inversion of control by Martin Odersky and Matthias Zenger
- Actors with Multi-Headed Message Receive Patterns by Martin Sulzmann
Books
- Actors In Scala by Philipp Haller and Frank Sommers
- Programming Erlang by Joe Armstrong
- Erlang and OTP in Action by Martin Logan, Eric Merritt, and Richard Carlsson
Implementations
- Akka Framework (alternative implementation of actors in Scala with a port of several Erlang behaviors and lots of other relized patterns for actors)
- Scalaz Actors (actor compositions, strategies and promises)
Presentations
- Actor Thinking by Dale Schumacher
- 1000 Year-old Design Patterns by Ulf Wiger
- Actor-based Programming by Jamie Ridgway
- Школа Актерского Мастерства by Vasil Remeniuk
Examples from highscalability.com
- Simple queuing service (SQS) - this service provides an internet scale queuing service for storing messages. Distributed actors put work on the queue and take work off the queue. Typical use: a centralized work queue. You put jobs on the queue and different actors can pop work of the queue and process them when they get CPU time. Part of scalability. Have any number of producers and consumers. You don't worry about it. Queues are spread across multiple machines and multiple data centers.
Answer
This is related to a previous question, if not exactly the same!
It's not such a simple question because the actor model of concurrency allows for many different types of applications to be built, from a stateful single-VM application (with a few separate actor classes) to a stateless cluster of thousands of instances of an actor class.
The core principles are the same however:
- Never expose an actor's state
- Communicate solely via the passing of immutable messages