{
    "slug": "actor_model",
    "term": "Actor Model",
    "category": "concurrency",
    "difficulty": "advanced",
    "short": "The Actor Model treats everything as an actor — isolated units that communicate only by message passing, never sharing state — eliminating race conditions by design.",
    "long": "Actor: unit of computation with private state, a mailbox, and behaviour. Actors communicate only by sending messages — no shared memory. On receiving a message, an actor can: send messages to other actors, create new actors, change its next behaviour. Benefits: no race conditions (no shared state), location transparency (actor can be remote), fault tolerance (supervisors restart failed actors). Implementations: Erlang/OTP (pioneered it), Akka (JVM), Elixir, Microsoft Orleans. PHP: not native but Amp/Revolt can approximate it. Vs CSP (Go channels): actors own their mailbox; CSP channels are first-class.",
    "aliases": [],
    "tags": [
        "concurrency",
        "actor-model",
        "distributed",
        "erlang"
    ],
    "misconception": "Actor model eliminates all concurrency bugs — message ordering between actors isn't guaranteed (unless you use request-response), and actors can still deadlock if they wait for each other.",
    "why_it_matters": "Actor model makes distributed, fault-tolerant systems tractable — it's the model behind WhatsApp (Erlang), Discord (Elixir), and high-availability telecom systems.",
    "common_mistakes": [
        "Sharing state between actors — defeats the model.",
        "Tight coupling via synchronous request-response chains — creates hidden deadlocks.",
        "Not implementing supervision trees — actors need a restart strategy."
    ],
    "when_to_use": [
        "Highly concurrent systems where shared mutable state causes contention — actors eliminate locks.",
        "Distributed systems where actors can be transparently placed on different nodes.",
        "Fault-tolerant systems — supervisor hierarchies let actors restart failed children automatically.",
        "Event-driven simulations, game engines, or real-time systems with many independent entities."
    ],
    "avoid_when": [
        "Simple single-threaded workloads — actor overhead adds complexity with no concurrency benefit.",
        "Synchronous request-reply patterns where actors must coordinate tightly — message passing adds latency.",
        "Teams unfamiliar with the paradigm — actor bugs (deadlocks via circular message waits) are subtle.",
        "Low-level performance code where actor message dispatch overhead is measurable."
    ],
    "related": [
        "concurrency_vs_parallelism",
        "event_driven_concurrency",
        "producer_consumer",
        "php_swoole_concurrency"
    ],
    "prerequisites": [
        "concurrency_vs_parallelism",
        "event_driven_concurrency"
    ],
    "refs": [
        "https://en.wikipedia.org/wiki/Actor_model"
    ],
    "bad_code": "// Shared state between actors — violates the model:\nclass OrderActor {\n    public static array $orders = []; // Shared — race condition\n}",
    "good_code": "// Elixir-style actor (conceptual PHP with Amp):\n// Each actor has private state, communicates via channel:\n$channel = new Amp\\Channel\\Channel();\n$actor = Amp\\async(function() use ($channel) {\n    $state = [];\n    while ($msg = $channel->receive()) {\n        // Process msg, update private $state\n        // Send reply back via $msg['replyTo']\n    }\n});",
    "quick_fix": "Keep actor state private. Communicate only via messages. Implement supervision to restart failed actors. Avoid synchronous blocking calls between actors.",
    "severity": "info",
    "effort": "high",
    "created": "2026-03-23",
    "updated": "2026-03-25",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/actor_model",
        "html_url": "https://codeclaritylab.com/glossary/actor_model",
        "json_url": "https://codeclaritylab.com/glossary/actor_model.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[Actor Model](https://codeclaritylab.com/glossary/actor_model) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/actor_model"
            }
        }
    }
}