PersistentView used to be a construct offered in Akka replicating the persistent message stream of a PersistentActor. Implementation classes received the message stream directly from the Journal. These messages could be processed to update internal state in order to maintain an (eventual consistent) view of the state of the corresponding persistent actor. It is now deprecated in Akka 2.5.

QueryView is a lightweight implementation of PersistentView based on the stream API, which snapshots its local cache of the data it builds up from the events related to PersistentActor of interest. it does not persist its data and relies only on regular snapshotting of the data it reads.

QueryView snapshots the cached data itself and caches the offsets as persisted events. Note that a given QueryView does not have to cache the full set of data it reads from a persistent Actor and can pick and choose the data it caches internally.

The basis of using PersistenceQuery can be seen in QueryInspector which creates a stream of events from a PersistentActor and will receive all the following events from that actor in its inbox. That would be the starting point to look at. AccountInspectApp demonstrates this.

AccountQueryApp fires up a persistent actor as well as a reader actor. The reader receives not only the events from the write actor after the reader was created, but also the past events. the reader receives the persisted events from write actor's journal and updates its cache and responds to read queries based on its cache of the data at the time. the result will be "eventually consistent" after the reader's cache of data is in sync with the write side.

Note that since the view actor is itself a persistent actor and persists and snapshots its own data, using the queryView needs slight considerations if there are going to be multiple copies of it in different nodes. Easiest solution would be to have it as a cluster singleton. Better solution would be to set its persistence Id configurable based on a constructor parameter. This way there will not be any mix-up with the persisted messages/snapshots.