What is the actor model (Akka-style), and how does it sidestep shared-memory concurrency problems?

#Concurrency without shared memory

Most concurrency bugs — race conditions, deadlocks, visibility bugs where one thread never observes another thread's write — trace back to the same root cause: multiple threads reading and writing the same mutable memory, coordinated (or not) with locks. Locks fix correctness at the cost of throughput and introduce their own failure modes: deadlock, livelock, priority inversion, lock convoy. The actor model, introduced by Carl Hewitt in 1973 and popularized in production systems by Erlang/OTP and later by Akka on the JVM, sidesteps the whole problem by removing shared mutable memory as an option in the first place.

#The three guarantees an actor makes

1. An actor's internal state is private — nothing outside the actor can read or write it directly, not even another actor holding a reference to it.
2. The only way to interact with an actor is by sending it an asynchronous, immutable message, which lands in that actor's mailbox, a queue.
3. An actor processes exactly one message at a time, start to finish, before looking at the next one in its mailbox.

Guarantee 3 is the one that matters most for concurrency: because an actor is effectively single-threaded with respect to its own state, there is never a race between two messages being handled "at once" for the same actor. You get the safety of a single-threaded mental model for free, while still getting real concurrency system-wide, because different actors process their own mailboxes in parallel, on a shared pool of underlying threads the actor system manages for you (Akka calls this component a dispatcher).

#What you trade away

No shared state means no free lunch on cross-actor invariants. If two actors need a consistent joint view — transferring money between two account actors, for instance — you cannot simply take a lock across both; you model the coordination explicitly, with a request/response protocol, a multi-step conversation, or by routing both operations through a single owning actor (or a saga / process-manager pattern) that serializes the decision. Failure handling is likewise explicit and structural rather than defensive: Akka propagates a crashed actor's failure up to a supervisor, which decides whether to restart it, resume it, stop it, or escalate further. This is the Erlang "let it crash" philosophy — rather than defensively coding every possible failure path inline inside each message handler, you isolate the failure to one actor and let a supervisor above it decide how to recover.

#Code

Below, an AccountActor holds its balance as an immutable local value threaded through recursive calls to apply, a common and idiomatic way to model actor state functionally in Akka Typed: each message handler returns the Behavior that should process the next message, closing over the new state instead of mutating a field.

Wrap long lines
import akka.actor.typed.{ActorRef, Behavior}
import akka.actor.typed.scaladsl.Behaviors

object AccountActor {
  sealed trait Command
  final case class Deposit(amount: BigDecimal) extends Command
  final case class Withdraw(amount: BigDecimal, replyTo: ActorRef[WithdrawResult]) extends Command
  final case class GetBalance(replyTo: ActorRef[BigDecimal]) extends Command

  sealed trait WithdrawResult
  case object Approved extends WithdrawResult
  case object InsufficientFunds extends WithdrawResult

  def apply(balance: BigDecimal = 0): Behavior[Command] =
    Behaviors.receiveMessage {
      case Deposit(amount) =>
        apply(balance + amount)

      case Withdraw(amount, replyTo) if amount <= balance =>
        replyTo ! Approved
        apply(balance - amount)

      case Withdraw(_, replyTo) =>
        replyTo ! InsufficientFunds
        Behaviors.same

      case GetBalance(replyTo) =>
        replyTo ! balance
        Behaviors.same
    }
}

No field on this actor is ever mutated and no lock ever appears, yet a thousand concurrent Deposit and Withdraw messages sent to the same ActorRef[Command] are still handled with perfect internal consistency, because the actor's mailbox serializes them one at a time before apply ever sees the next message.