Actor have their own state and this is an essencial concept for achieving a near real-time architecture with Akka. Otherwise, a stateless architecture where, for each request, the state needs to be recovered from the persistence layer (database), processed and updated, would fit most of the requirements (and the use of a framework like Akka would be pointless). A stateful architecture is the main reason to use actor model so we can achieve high throughput.
Said the importance of the internal state of the actors, how much information should be kept in this state? Does Akka impose some kind of limitation? Or the JVM memory is the limit?
Is there any guideline on how large the information should be to be maintained within an actor?
This is highly dependent on the type message and size of the messages. You are only limited by your machines memory size. If you only have many stateful actors it might be easier to run them using Akka Cluster Sharding which distributed the actors to different machines
Indeed, the way we can achieve elasticity in our applications is spreading the actors among clusters with Akka Cluster. If the framework doesn’t have any technical limitation I think it depends on the design of the application to define it. My concern is how to tell when store information in the internal state of the actor and when we need to store it externally (persisted database or even Redis).