Your team is deciding whether to build a stateful system on the actor model rather than stateless services over a shared database. What do actors give you, where does the model break down, and how would you decide?

## Frame the choice honestly The actor model is not a general replacement for stateless services; it is a strong fit for one shape of problem and an awkward fit for others. The decision is about the *dominant access pattern*, plus the operational cost the team can carry. ## What the model genuinely gives you **Per-entity serialization for free.** One actor per entity means all operations on that entity are processed one at a time. The read-modify-write race that forces pessimistic locking or optimistic-retry loops in a database design simply does not exist. For high-contention entities this is a real throughput win, not just a simplicity win. **In-memory state with an owner.** The entity's state lives where the work happens, so a hot entity does not pay a database round trip per operation. Because exactly one actor owns it, there is no cache-coherence problem across nodes. **Fault isolation with a policy.** Supervision means a failure damages one entity's state and a parent decides the response, rather than an exception propagating through a shared request path. **Natural sharding and location transparency.** Addressing by identity gives you the partition key, and messages can cross a network without changing the programming model. **Domain fit.** Anything with identity and a lifecycle — a device, a session, a match, a subscription — maps to an actor almost one-to-one, and state machines are pleasant to write as behaviour changes. ## Where it breaks down **Cross-entity consistency.** There is no transaction spanning actors. Any invariant over two entities (transfer funds, reserve inventory across warehouses) needs an explicit protocol: a saga with compensations, a coordinator actor, or a designated owner for the combined invariant. Teams used to a database transaction routinely underestimate this, and it is the single most common reason an actor design becomes painful. **Hot keys.** Serialization is per actor, so one entity's throughput is capped at one core. A celebrity account, a popular product, a global counter — each becomes a bottleneck. The fix is to split it (per-shard sub-actors that aggregate) which reintroduces cross-entity coordination. **Debuggability.** Asynchronous messaging discards the call stack. 'Why did this actor receive this message' requires correlation ids and distributed tracing that you must build in from day one; retrofitting it is expensive. Nondeterministic interleaving also makes tests flakier and reproduction harder. **Weak guarantees by default.** At-most-once delivery, pairwise-only ordering, and no automatic retry mean protocols need timeouts, idempotency and de-duplication in code that would be implicit in a synchronous call. **Durability is your problem.** In-memory state vanishes on restart or rebalance. You must add event sourcing with snapshots or write-through persistence — a substantial subsystem with its own schema-evolution and replay concerns. **Cluster operations.** A stateful cluster brings membership, split-brain protection, rebalancing when nodes join or leave, and rolling upgrades that must move live state. Stateless services over a database push all of that onto the database, which is usually the more familiar operational burden. **Typing and protocol discipline.** In many runtimes messages are loosely typed, so protocol errors surface at runtime; keeping a protocol coherent across many actor types requires deliberate design and review. ## How I would decide Approve actors when most of these hold: a large population of independent entities; repeated stateful interactions per entity (not a single read); genuine contention per entity that a database would have to lock around; latency requirements that make a database round trip per operation costly; a natural partition key with no unfixable hot key; a team willing to own durability, tracing and cluster operations. Prefer stateless services over a database when: the workload is dominated by cross-entity queries, reports and multi-entity transactions; state is naturally relational and consistency requirements are strong; the team's operational strength is the database; or the traffic simply does not justify keeping state in memory. **Hybrids are usually right.** Use actors for the hot, stateful, entity-shaped core and keep everything else stateless with a database as the source of truth. Also consider the middle options: partitioned stateless consumers over a log (per-key ordering with durability, no in-memory ownership), or channel/CSP-style pipelines when the shape is a data flow rather than a population of entities. Finally, name the reversal cost. Moving an entity's state from an actor into a database later is a moderate refactor if durability was already event-sourced, and a rewrite if state exists only in memory. That argues for persisting from the start even when it is not yet needed. ## Interview delivery Give the fit criteria, the four or five real breakdowns (cross-entity transactions, hot keys, debuggability, weak delivery guarantees, durability and cluster ops), state the decision rule in terms of the dominant access pattern, and volunteer the hybrid as the usual answer. Concluding with the reversal cost signals genuine decision-making rather than technology preference.