XenonStack Insights Akka Framework: Actors, Clustering and Licensing

What is the Akka framework and when does it fit?

Akka is a toolkit for building concurrent, distributed and fault-tolerant applications on the JVM in Java or Scala. Its core idea is the actor model: according to the Akka documentation, it is "a higher level of abstraction for writing concurrent and distributed systems", where actors keep their own state and talk only through messages, so developers do not write explicit locking or thread management.

For a CTO or enterprise architect the question is less "how do actors work" and more "is this the right foundation, and on what licence?". This guide answers both: the mechanics that matter for design reviews, and the licensing choice between Akka and Apache Pekko. If you are comparing concurrency styles, see also our guides to coroutines and microservices in Java and Go.

What is Akka and what is it used for today?

The table summarises the main parts of the Akka stack as described on its own sites. Check the current release and module names on doc.akka.io before you plan, because the documentation pages show different library versions in different sections.

Typical candidates are IoT device models, transaction and event processing, service gateways and long-running workflows. These are design patterns rather than benchmarks; measure message throughput with your own load test on your own hardware.

How does the actor model work in Akka?

In Akka Typed, an actor reference is typed: an ActorRef[T] accepts only messages of type T, so the set of accepted messages defines the actor's protocol and is checked at compile time. Sending with tell (the ! operator) is asynchronous and does not block the caller's thread.

Each actor processes one message at a time, so its internal state needs no synchronized blocks or atomic counters. State changes come from returning a new behaviour rather than mutating variables. Messages should be immutable, and an actor should not share mutable state with another actor.

How does Akka handle failure?

Supervision decides what happens when an actor throws. According to the fault tolerance documentation, a typed actor that throws an unexpected exception is stopped by default, unlike classic actors, which restart by default. You choose a strategy by wrapping the behaviour with Behaviors.supervise.

A parent must watch a child to learn that it terminated. If the parent does not handle the resulting Terminated signal, it fails with a DeathPactException. Plan this in the design, not after the first production incident. Our post on reactive programming for monitoring platforms covers the observability side.

When should you use tell and when ask?

The interaction patterns documentation describes tell as fire-and-forget: the sender gets no confirmation that the message was received, processed or failed, and an unbounded inbox can grow until memory runs out. Ask suits one-to-one request and response when the sender must know a message was handled, needs to resend after a delay or needs backpressure.

Ask has limits: one response per ask, no notification to the receiver on timeout, and timeouts are hard to tune, especially with chained asks. Outside an actor, ask returns a Future or CompletionStage whose callbacks run on another thread, so avoid touching mutable state in them. Inside an actor, use pipeToSelf to turn a completed Future into a message the actor handles itself.

How do persistence and cluster sharding fit together?

According to the persistence documentation, an event-sourced actor stores only the events it persists, not its full state, and rebuilds state by replaying them. Snapshots can shorten recovery. An EventSourcedBehavior is defined by a persistence ID, an empty state, a command handler and an event handler, and state changes happen only in the event handler. Only one active actor should exist per persistence ID, which is why persistence is commonly paired with sharding.

Cluster Sharding distributes entities across nodes and addresses each by its entity ID, so senders do not need to know where an entity runs. Per its docs, the default is 1000 shards, the shard for an ID must stay the same or an entity could start in two places, and the default allocation strategy gives new shards to the node with the fewest. Remembering entities is optional and off by default, and entity state is restored only if the entity is persistent.

Akka or Apache Pekko: which licence decision applies?

Akka's announcement of 7 September 2022 states that the new licence is the Business Source License (BSL) v1.1. Per the announcement and the licence FAQ, development and testing are free, production use requires a commercial licence from Lightbend, and BSL code reverts to Apache 2.0 three years after that release. Apache Pekko is an open-source framework with Java and Scala APIs that the Pekko site describes as a fork of Akka 2.6.x, made before the BSL, and its docs list the Apache-2.0 licence.

Licence terms, pricing and which versions are covered change over time and are not legal advice: confirm them on the official pages and with your legal team before committing.

Where does Akka fit in an agentic AI estate?

akka.io now positions Akka as an agentic AI platform, and actors map naturally to long-running agents that hold state and exchange messages. What the actor model does not give you is business governance: which agent may take which action, under which policy, with what evidence. That layer sits above the runtime. For example, ElixirData Context OS gathers the context agents need, checks policy and authority before they act, and keeps an audit trail of each decision, and its Decision Review Agent reviews past agent decisions for inconsistencies and outcome patterns. See also our guide to agentic workflows.

When should you not use Akka?

• Simple request and response services with little shared state: a conventional framework is easier to hire for and operate.
• Teams without time to learn message protocols, supervision and cluster operations.
• Organisations that cannot accept the BSL terms and have no appetite to adopt Pekko.

What is a sensible adoption sequence?

1. Decide the licence route (Akka commercial or Pekko) with legal and procurement.
2. Prototype one bounded workflow with typed actors and an explicit supervision strategy.
3. Add event sourcing only where history or recovery matters.
4. Add Cluster Sharding when one node can no longer hold the entities, and load test with your own data.
5. Instrument and review failures before widening scope.

To map one decision your actor-based agents should make, and the context and policy it depends on, book a Context Workshop. See what happens in the workshop.

Frequently asked questions

What is the Akka framework?

A JVM toolkit for concurrent, distributed and fault-tolerant applications built on the actor model, with Java and Scala APIs.

What happens when an Akka Typed actor fails?

By default it is stopped. You can choose restart, resume or stop with Behaviors.supervise, per the Akka fault tolerance documentation.

Should I use tell or ask?

Use tell for fire-and-forget messaging and throughput. Use ask when the sender must know a message was handled, with a carefully chosen timeout.

Is Akka free for production use?

Per Akka's licence FAQ, production use under the BSL requires a commercial licence from Lightbend; development and testing are free. Confirm current terms on the official page.

What is Apache Pekko?

An Apache-licensed open-source framework that the Pekko site describes as a fork of Akka 2.6.x.