We can store with read side processor and use later some state in cassandra by key, but it can be an entity state which can be queried by id also.
Because of event consistency we can not use some updates like “a = a + 1” in cassandra, but entity state can be used for this. May be cassandra have some performace benefits on read by key, over entity recover and responce?
The entity can only be adressed by it’s identity so it can be used for single entity queries when you know the specific id. It can be very efficient for this since once loaded it’s already in memory and doesn’t have to hit the data store for the subsequent queries of same id.
With the read side processor you can create other projections of the data that are tailored to the (other) queries that are needed, with different indexes.
From my expiriencing modeling query by entity id (write or read side) mainly depends on entity time in memory.
If an entity is most of the time in memory (restored) then it is, like @patriknw stated, more optimal to query write side then a read side (hitting memory and not store).
But if an entity is less time in memory (mostly passivated) then doing the restore just for read is less optimal (overhead - query list of events and restore oposite to query one row).
Br,
Alan
Additional note: Entity less time in memory also indicates that queries are done less frequent