I'm referring to this snippet in listing 8.7

eventLog.put(no, c)
onClose(updateState(c, currentState)(no))

In FP, we don't throw exceptions. So,
eventLog.put(no, c)
might fail silently in this case and we end up updating the state for an event that has not been journaled. It is not better to update the state using a callback to eventLog.put?

It is not more safe to update state as a callback of eventLog.put?
What if eventLog.put returns failed Future?


I read through the whole book and I have the following concern:

Akka scalability and clusters rely heavily on messages between actors. The book, on the other hand, advises to favor streams and Futures whenever possible, but streams don't play well with clusters in terms of backpressure. Moreover, the book carefully selects a problem that works well with reactive streams, while the domain of personal banking doesn't really do.
So how can I gain the goodness of backpressure, functional programming, type and compatibility and leverage Akka clusters to scale the AccountService (for example) over multiple nodes?

In the same context, the use of Future over Actor sounds a sound tradeoff, but Future runs on a single machine, while Actor is location transparent

I hope the author can clarify how pieces fit together to build an elastically scalable system that leverages the power of Akka clusters or something similar without compromising FP principles