actor model
A software design pattern used in systems that require concurrent computation where the primitive is an "actor": an object that reads messages sent to it and can react by concurrently (in any order or in parallel):
- deciding how to respond to following messages
- sending messages to other actors
- creating child actors
Actors may have private state but the only way to modify that state externally is through message sending.
A message can be sent to more than one actor. Every actor has an "address" and any actor that knows its address can send it messages.
Messages in an actor's maibox must be handled in first in first out (FIFO) order.
The benefits of this model include
- scalability of services by ensuring primitives only need to be aware of their own state and how to send messages
- the ability to separate and lift subsets of a system into remote systems without large amounts of refactoring
- the embracing of inconsistency as a core reality
- avoiding the need for locks or mutexes, which are common sources of failure