Modules: The High-Level View

Starting with the high-level view, we’ll walk through the different modules.
Akka is built up by a set of core modules that can be used altogether or in isolation.


  • Actors , which gives you:
    • Simple and high-level abstractions for concurrency and parallelism.
    • Asynchronous, non-blocking and highly performant event-driven programming model.
    • Very lightweight event-driven processes (create ~6.5 million actors on 4 G RAM).
  • Failure management through supervisor hierarchies with let-it-crash semantics. Excellent for writing highly fault-tolerant systems that never stop, systems that self-heal.
  • Software Transactional Memory (STM). (Distributed transactions coming soon).
  • Transactors: combine actors and STM into transactional actors. Allows you to compose atomic message flows with automatic rollback and retry.
  • Remote actors: highly performant distributed actors with remote supervision and error management.
  • Cluster membership management.
  • Scala and Java API.


  • Persistence: A set of pluggable back-end storage modules that works in sync with the STM.
    • Cassandra distributed and highly scalable database.
    • MongoDB document database.
    • Redis data structures database.
  • REST (JAX-RS): Expose actors as REST services.
  • Comet: Expose actors as Comet services.
  • Security: Digest and Kerberos based security.
  • Microkernel: Run Akka as a stand-alone self-hosted kernel.d

Remoting/Distributed services module

  • Scalability and High-Availability
  • Another dimensional fault tolerance (on JVM/box level)
  • Remote supervision and error managament
  • Run 1-100+ Akka instances

Transactors: Software Transactional Memory (STM) module

Actors are excellent for solving problems where you have many independent processes that can work in isolation and only interact with other Actors through message passing. This model fits many problems. But the actor model is unfortunately a terrible model for implementing truly shared state with the need to do multiple coordinated changes. E.g. when you need to have consensus and a stable view of state across many components. The classic example is the bank account where clients can deposit and withdraw, in which each operation needs to be atomic. For detailed discussion on the topic see this JavaOne presentation.

STM on the other hand is excellent for problems where you need consensus and a stable view of the state by providing compositional transactional shared state. Some of the really nice traits of STM are that transactions compose, and that it raises the abstraction level from lock-based concurrency.
Akkas’ Transactors, e.g. being able to optionally combine Actors and STM provides IMHO the best of the Actor model (concurrency and asynchronous event-based programming) and STM (compositional transactional shared state) by providing transactional, compositional,
asynchronous, event-based message flows.
  • Transactional (in-memory) Map, Vector & Reference
  • Implements the Clojure’s state model using Managed References and persistent data structures
  • The STM understands the Actor model, e.g.
    • allows you to orchestrate composed asynchronous message flows if you have a need for consensus across many Actors
    • is not tied to a specific thread but follows the message across thread boundaries
    • works with asynchronous calls (that never return)
  • Distributed transactions will come soon, backed up by ZooKeeper.

REST & Comet (push/streaming REST/AJAX) module

  • Expose Actors & Active Objects as REST services through JAX-RS
  • Expose Actors & Active Objects as Comet services through Atmosphere

Security module

  • Secure your Comet or REST services using HTTP Auth via easy-to-use annotations.
  • Both Digest and Kerberos security managers.

Persistence modules

  • Provides persistence abstractions exposed through Transactional Map, Vector & Reference
  • Works with the Software Transactional Memory to provide transactional storage.
  • Current back-ends are:
    • Cassandra
    • MongoDB
    • Redis


To be deployed in arbitrary servlet container


An Actor abstraction over AMQP. Producer and Consumer. Supervised for fault-tolerance.


Embedding servlet container implementing a full enterprise stack

Management and Monitoring

Exposes all configuration parameters, such as thread pools, queue sizes and current depth, fault rates etc. through:
  • JMX allowing both management and monitoring
  • w3c logging
This is part of the commercial offering.
Home Turn Off "Getting Started"