New Scala Akka library 2.3-M1 milestone release have Akka Persistence module, which was developed in collaboration of Akka team and Martin Krasser. It allows to have stateful actors to persist their internal state, so in case of JVM crash this state can be recovered. 

The key concept behind Akka Persistence is that instead of storing an actor’s state you persist the changes that are applied to it. These changes are immutable facts that are appended to a journal, which allows for very high transaction rates and efficient replication. Stateful actors are recovered by replaying stored changes, rebuilding the actors’ internal state.

Akka Persistence features in 2.3-M1 include:
 * event sourcing and command sourcing
 * automated and explicit recovery
 * state snapshots to reduce recovery times
 * journal and snapshot store plugin APIs
 * channels as gateways to other services
 * persistent FSMs

Martin Krasser about performance and limitations for Akka Persistence module :

I'd like to add some comments regarding akka-persistence performance and limitations of the current EventsourcedProcessor implementation. The following numbers were obtained running simple performance tests on a 2013 MBP with a LevelDB Java port as journal, using default JVM settings.

Command sourcing (i.e. sending Persistent messages to a Processor directly):
- throughput is 30-50k persistent messages per second
- a Processor actor can already be used under high load

Event sourcing (i.e. sending non-persistent commands to an EventsourcedProcessor, which internally persists events):

- an EventsourcedProcessor currently cannot be used under high load (throughput decreases)
- throughput currently very limited (< 4k persistent events per second).

I started to work on an optimization of EventsourcedProcessor where initial results show a throughput of approx. 15k commands per second (without decreasing under high load). This is approx. 1/3 of command sourcing (the test generated 1 persistent event per command). The optimization replaces the current stash-based approach with an internal command buffer actor that is communicated with using an ack protocol. This optimization will be available with the next (milestone) release and I'll see if I can push throughput further.

Except for the described event sourcing performance optimizations, no further optimization work has been done yet on akka-persistence. In this context, the performance numbers, especially for command sourcing, are a good starting point IMO. There's lot of room for further optimizations on which we'll work for upcoming releases.