These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
Thanks @volkerstampa!, i may need to use the conditional requests and i have also not thought about the locations affecting the global ID collision (since i was starting with just one location), but i may need that too... Also, i have some queries that are referred to just one place (which could be handled in the same way as orders on the order management example) but i also have many queries for finding places in a radius around a location, so it was clear to me that i needed a view with access to all the places for being able to do that second kind of queries.
What i am not sure if it is a good idea to make that big view also handle the search of the aggregates for the purpose of ID retrievals since it may be better to have a different view, or to use a simplified write model on the actor that receives the commands coming from the parsed data.
Also, if actors process messages sequentially, how would you handle concurrent queries? My concern is that if i create many copies of that view actor that has a big in-memory read model each, the resource usage could be quite higher than on the current backend. Is it possible / sensible to have child actors that share the state of that view actors? Or.. does it make sense to create threads on a view actor to handle more queries without necessarily creating more copies of the actor?