TechPrufer
Get started
Temporal
Temporal logoTemporal · Feature trail

Actor Model Abstraction

3 posts · May 2021 – Jun 2026

What this trail covers

Temporal Workflows can be used to model the Actor Model, enabling durable, stateful, and message-driven entities. This post details how Temporal's features like Signals, Updates, Queries, and Child Workflows map to the core tenets of the Actor Model (message passing, state maintenance, and actor creation). It highlights the use of Workflow Updates for request/response patterns and the combination of Signals and Queries for external client interactions. The ability to create child workflows is also leveraged. This post details building a telecommunications customer service chatbot that treats each conversation as a persistent workflow, enabling stateless applications, infinite scalability, and resilience to failures. The chatbot maintains perfect conversation context across any number of pod restarts, deployments, or scaling events. Conversations are managed by Temporal Workflows, with automatic lifecycle management that ends conversations after inactivity or explicit user farewell. The system generates summaries and satisfaction scores for retrieved conversations. The implementation uses Java and interacts with LLMs and external tools via Activities, passing the full conversation history for context. This approach offers simplified state management, infinite scalability, resilient workflows, maintainable design, rich context management, transparent state inspection, and robust error handling compared to traditional session-based implementations.

All Temporal trails
  1. Loyalty Points with Entity Workflows in TemporalThis post details the application of the Actor Model abstraction using Temporal Workflows for managing loyalty points. It describes how each customer is represented by a dedicated Workflow (entity workflow) that maintains state (points balance, tier status) in memory. Purchases are handled via Signals, redemptions via Updates (with validation), and balance display via Queries. This approach eliminates the need for cron jobs and database locking, ensuring real-time consistency and durability for customer loyalty accounts.
  2. Durable Player Sessions with Temporal Actor WorkflowsThis post details how to model each player in a multiplayer game as their own durable, independently-running Temporal Workflow. This approach addresses the common problem of player state living in memory and being lost on server crashes. Each player Workflow is identified by their player ID and manages state like inventory, health, and position. Game actions such as joining a room, executing combat moves, or updating leaderboards are driven through Activities invoked by the Workflow. The post highlights that when a server goes down, the Workflow resumes on another Worker from its last point of execution without state loss or requiring reconnection logic. It also mentions that Continue-As-New handles long-running sessions to prevent unbounded history growth.
  3. Building a persistent conversational AI chatbot with TemporalThis post demonstrates how to build a persistent conversational AI chatbot by treating each conversation as a Temporal Workflow. It details the functional and non-functional requirements for such a chatbot, contrasting a traditional stateful session-based architecture with a Temporal-based stateless approach. The core of the implementation involves mapping chatbot scenarios to a state machine/conversation graph, where each user message is processed as a Temporal Signal. Activities within the Workflow interact with LLMs and external tools, passing the full conversation history for context. The post highlights advantages such as simplified state management, infinite scalability, resilient workflows, maintainable design, rich context management, transparent state inspection, and robust error handling. It also briefly touches upon integrating with MCP servers and provides a code snippet for the `ChatbotService.java` class.
  4. Managing very long-running Workflows with TemporalThis post introduces the concept of 'Entity Workflows' as a pattern for representing long-running, potentially indefinite processes or entities. It details how to keep these workflows running indefinitely by managing Temporal's Event History limits (50K events or 50MB) using the Continue-As-New feature. The post explains the mechanics of Continue-As-New, including how to handle inputs and pending signals to avoid data loss or workflow termination. It also touches upon interacting with these workflows via Signals, Updates, and Queries.
  5. Customer Workflows in Loyalty Programs with TemporalThis post provides a concrete implementation example of the Actor Model pattern using Temporal Workflows for a customer loyalty program. It details how Temporal Workflows map to the core requirements of the Actor Model: sending/receiving messages (via Signals), creating new Actors (via spawning new Workflows), and maintaining state. It also discusses the practical considerations of event history size and the use of 'Continue-As-New' for long-lived workflows, specifically in the context of the loyalty program example.
  7. Workflows as Actors: Is it really possible?This post introduces the concept of using Temporal Workflows as an implementation of the Actor Model. It maps the core characteristics of Actors (message passing, state maintenance, creating other actors) to specific Temporal features: Signals, Updates, Queries, and Child Workflows. It provides code examples in Go to illustrate how to implement these patterns, focusing on Workflow Updates for synchronous communication and the Signal-Query pattern for external client interactions. The post also touches on the implications of creating child workflows for actor hierarchies.
  8. The curse of the A-wordThis post argues that the term 'actor' is a 'minefield of conflations' due to misunderstandings around distributed vs. local actors, supervision trees, one-way messages, and state transitions. The author advocates for using terms like 'grains' or 'Cloud Native Objects' to reduce cognitive load and better convey the benefits of systems like Orleans, which are built on Actor Model principles but have distinct implementations. The post contrasts Orleans' default asynchronous RPC with traditional actor model's preference for one-way messages and discusses the benefits of its virtual actor lifecycle management over supervision trees.