Understanding Akka Fault Tolerance

Question

I am digging into Akka and was just looking at their fault tolerance example , and am trying to understand it.

1. Why couldn't I just implement all those same types ( Worker , Listener , CounterService , etc.) in "pure Java" (no Akka). What infrastructure is Akka adding here out of the box?
2. In that diagram, what does Storage represent? An RDBMS? A Java app monitoring an RDBMS? A JDBC driver?
3. That's great if Storage is a Java app and can throw a StorageException back to requesters, but what if the network between Storage and CounterService is severed or has transport-level issues? Does this whole diagram still work (if so, how?!? ) or does Akka only provide "application-layer" fault tolerance? In the latter case, how can Java/Akka handle hardware- or network-level failures?

Answer 1

1. Akka is based of the design pattern of actors, you can implement this pattern yourself, just like you could with MVC. I would say the best thing akka does for you is all the reactive stuff that will minize the amount of resources actors need.

2. You can consider Storage as just being state or holding some state of the application.

3. I think the main thing people refer to when they talk about fault tolerance is that because you can easily have distrubuted actors, and use something like the reliable proxy pattern http://doc.akka.io/docs/akka/snapshot/contrib/reliable-proxy.html you make your application in a way that it will keep functioning untill the very last node dies, and you wont lose any messages if you always implemented that pattern. So it refers to message loss. Everything is in terms of message in akka, you don't usually have requests that is not a very good idea because it is blocking, instead you use Futures if needed. If your hardware stops functioning you wont retrieve the value of the future in the time you specify, and you can handle the failure yourself.