wal.sh
home > research > event-driven-architectures-actor-model · Jan 01, 2024

Event-Driven Architectures and the Actor Model

event-driven architectureactor modeldistributed systemsasynchronous messagingevent sourcingcqrsevent-carried state transferconcurrent computationevent stream processingpublish-subscribefault tolerancescalabilityreal-time systems

Event-Driven Architectures and the Actor Model

Table of Contents

1. Summary: Event-Driven Architectures & Actor Model

Event-Driven Architectures (EDA) and the Actor Model both provide patterns for asynchronous, distributed computing. The EDA communicates through events, pieces of data that signify a state change, propagating them as messages to interested consumers. The Actor Model utilizes individual acting entities, or actors, each with its mailbox and behavior, processing incoming messages asynchronously.

In EDA, several styles exist, including event sourcing, Commands Query Responsibility Segregation (CQRS), and event-carried state transfer. Event sourcing concerns capturing all changes as events, offering strong audit trails and temporal queries. CQRS divides an application into command and query models, reducing contention and complexity. Event-carried state transfer involves sharing state updates via events reducing service dependency.

The Actor Model is an architectural model for concurrent computation in distributed systems, with actors being the universal primitives. Actors encapsulate state and behavior, communicate through asynchronous messaging, and dynamically create other actors. They provide high-level abstractions for distributed and concurrent computation.

Two parallel clusters comparing event-driven architecture (publisher, event bus, log, subscribers) against the actor model (sender, mailbox, actor with encapsulated state, spawned child, reply actor), with yellow note shapes between them highlighting differences in addressing, state ownership, and coupling.

Figure 1: Side-by-side: an EDA pub/sub bus delivering events to subscribers vs an actor model where senders address mailboxes directly, with call-outs marking where the two paradigms diverge (addressing, state, coupling).

2. Acronyms

3. Impact

EDA and Actor Model both cater to the increasing demand for high-concurrency, distributed systems. They can handle high volumes of data changes and operations, allowing robust, flexible, and scalable applications. However, they require careful design to manage consistency and fault tolerance effectively. They don't naturally provide the ACID guarantees common to traditional relational database operations.

Moreover, implementing EDA and Actor Model entails a shift in thinking - strong emphasis on message passing, state encapsulation, and asynchronicity. They are powerful, but they may not be suitable for all types of applications. It's vital to evaluate fit and ROI based on specific needs.

Thoughtful implementation of EDA might lead to systems that can respond in real time to information updates, learning from them and dynamically adjusting their operation. In a wider perspective, this could pave the way for more adaptive, intelligent systems, impacting human destiny. Yet, this also highlights the increasing dependency on digital systems and their reliability.

4. Code

EDA in Clojure can be implemented using libraries like core.async for asynchronous communication. The Actor Model can be created with pulsar. 

(ns eda-example
  (:require [clojure.core.async :as async]))

(def updates (async/chan))

;; Producer
(async/go-loop []
  (async/>! updates (generate-update))
  (async/<! (async/timeout 1000))
  (recur))

;; Consumer
(async/go-loop []
  (let [update (async/<! updates)]
    (process-update update))
  (recur))

5. Questions

  1. What are the primary trade-offs in selecting an event-driven architecture versus a more traditional, request-response model?
  2. Given a system with a mix of fast and slow consumers, how might an event-driven architecture be designed to prevent slow consumers from becoming a bottleneck?
  3. How does the Actor Model handle failures and ensure message delivery in a distributed environment?

6. 2026 Landscape

The actor model and event-driven architecture have each matured significantly since

  1. This section surveys what changed, what stabilized into mainstream practice,

and where the two paradigms are converging — particularly in agentic AI systems.

6.1. Actor Model Implementations

6.1.1. JVM: Akka to Pekko

Lightbend's 2022 license change for Akka (moving away from Apache 2.0 for newer versions) prompted the Apache Software Foundation to accept the pekko fork in 2023. By 2026 Apache Pekko has become the canonical JVM actor framework for open-source projects. The API surface is deliberately compatible: typed actors, cluster sharding, persistence, and streams all carry over. Teams migrating from Akka 2.6.x can rename the akka namespace to org.apache.pekko and rebuild with minimal friction.

Microsoft Orleans, originally a research project, matured to a fully open-source virtual actor (grains) framework targeting .NET. The key abstraction is grain activation: the Orleans runtime finds or creates a grain instance wherever it is needed, making location transparency a first-class runtime concern rather than a library pattern.

6.1.2. BEAM: Elixir, OTP, and LiveView

The Erlang/OTP actor model remains the gold standard for fault-tolerant, high-concurrency systems. Every Elixir GenServer is an OTP actor with a supervised mailbox; the supervision tree is the system's fault-isolation boundary.

Phoenix LiveView takes this further: each connected browser session runs as an Elixir process on the server. The process holds UI state, receives user events via WebSocket, and sends diffs back. This is an actor-like UI paradigm where the traditional client-side framework collapses into per-session server processes — a concrete demonstration that the actor model scales to interactive UIs.

6.1.3. Cloud and Edge: Durable Objects and Wasm Actors

Cloudflare Durable Objects are the closest thing to the actor model available in a serverless edge environment. A Durable Object instance is:

  • single-threaded (no concurrency conflicts within an object),
  • location-transparent (the platform routes requests to the correct shard),
  • persistent (attached storage survives cold starts),
  • addressable by a stable ID (analogous to an actor reference or mailbox address).

The wake/get model — wake the object if dormant, route the request, let it sleep again — maps cleanly onto the virtual actor pattern from Orleans.

Fermyon Spin (WebAssembly components) extends this model to heterogeneous runtimes. A Wasm component implementing a message handler interface can function as an actor regardless of its source language, with the Spin host providing the mailbox and scheduling abstraction.

6.2. Event-Driven Patterns That Matured

6.2.1. Event Sourcing and CQRS Mainstream

Event sourcing and CQRS moved from architectural experiment to default recommendation in high-throughput domains. Mature tooling includes:

  • Axon Framework (Java/Kotlin): opinionated framework enforcing command, event, and query models with built-in sagas and deadlines.
  • EventStoreDB: purpose-built append-only event log with built-in projections, persistent subscriptions, and a stream-per-aggregate model.
  • Marten (.NET): PostgreSQL as an event store using JSONB, enabling teams to adopt event sourcing without a dedicated infrastructure dependency.

6.2.2. Change Data Capture as Event Source

Debezium established change data capture (CDC) as a first-class integration pattern. A Debezium connector tails a database's write-ahead log and emits row-level change events to Kafka. This makes any existing relational database a source of truth for downstream event streams without application-level instrumentation — a pragmatic bridge between legacy persistence and event-driven consumers.

6.2.3. CloudEvents as Standard Envelope

The CNCF CloudEvents specification (v1.0, widely adopted by 2026) provides a vendor-neutral event envelope: a small set of required attributes (id, source, type, specversion) plus optional extensions. CloudEvents decouples event producers from consumers at the schema level — a Kafka message, an HTTP webhook, and a gRPC call can all carry the same CloudEvents envelope, enabling routing and filtering infrastructure that is transport-agnostic.

Debezium CDC events, Eventarc (GCP), EventBridge (AWS), and Azure Event Grid all emit or accept CloudEvents, making it the HTTP/1.1 of event transport: not exciting, but now the assumed baseline.

6.2.4. Async Rust and Go Channels

tokio in Rust provides mpsc and broadcast channels that function as lightweight actor mailboxes. The actix and xtra crates build formal actor runtimes on top of tokio. The combination of Rust's ownership model and tokio's cooperative scheduler produces actor systems with predictable memory behavior and no GC pauses.

Go's goroutines and channels remain the textbook example of communicating sequential processes (CSP) — an actor-adjacent model where channels are first-class values rather than bound to a particular goroutine identity.

6.3. Agentic Systems as Actor Systems

The structural parallel between the actor model and AI agent architectures is not coincidental. An AI agent exhibits all the defining properties of an actor:

Actor property AI agent equivalent
Receives messages Accepts tool call results, user turns, MCP events
Maintains private state Context window, memory store, task queue
Sends messages Issues tool calls, spawns sub-agents, emits logs
Spawns children Delegates sub-tasks to specialized agents
Supervised Orchestrator detects failure, retries or escalates

Model Context Protocol (MCP) is the message-passing layer. MCP tool calls are asynchronous message sends; MCP servers are actor-like processes with their own state and capabilities. The protocol enforces the same decoupling that Akka actor references enforce: callers hold a capability reference, not a direct object.

The Memory-Centric Execution (MCE) pattern from our Q4 2024 agentic systems research maps directly onto supervisor hierarchies. A memory actor holds durable state across agent invocations; task actors are spawned for each unit of work; a supervisor actor monitors liveness and handles failure modes. The convergence is substantive: the theoretical foundations of the actor model from the 1970s apply without modification to multi-agent AI orchestration in 2026.

See Agentic Systems Q4 2024 for the MCE pattern detail and orchestration diagrams.

Ecosystem map comparing actor model implementations in 2026 across six clusters: JVM (Apache Pekko, Axon, Orleans), BEAM (OTP GenServer, Elixir, Phoenix LiveView), Cloud/Edge (Cloudflare Durable Objects, Spin/Fermyon, EventStoreDB), Clojure (core.async, missionary, Pathom 3, Babashka), AI Agents (AI agent, MCP, MCE pattern), and Infra/Standards (CloudEvents, Debezium, tokio/Rust). Dashed edges connect structurally equivalent concepts across ecosystems.

Figure 2: Actor model implementations across runtimes, edge platforms, and AI agent systems as of 2026. Columns group by ecosystem; dashed edges mark conceptual mappings between paradigms.

6.4. Clojure-Specific Updates

core.async remains the standard channel-based concurrency library. Its CSP model (go-blocks communicating over channels) is well understood, well documented, and stable. For most Clojure event-processing workloads it remains the correct choice.

missionary is gaining adoption for dataflow-style reactive programming. Where core.async models concurrency as explicit channel operations, missionary models it as composable flows using monadic abstractions. The tradeoffs are real: missionary offers better composition for complex derived state, while core.async is more approachable for team code reviews and operational debugging.

Pathom 3 implements a resolver graph where each resolver is a function from input attributes to output attributes. The runtime dispatches over the graph to satisfy a query, backtracking and parallelizing resolver invocations as needed. This is semantically actor-like: each resolver is stateless but the graph's execution engine maintains scheduling state, and resolvers can themselves invoke async channels or missionary flows.

Babashka enables lightweight event processing scripts that run on the JVM with fast startup. Its GraalVM-compiled binary can consume events from files, HTTP endpoints, or stdin and route them to downstream handlers. For edge preprocessing before ingestion into a Kafka topic, Babashka scripts offer a practical alternative to full JVM startup overhead. See the 2026 REPL-Driven Flight Tracking research for a worked example of Babashka processing ADS-B event streams.

7. Related

8. References