These are chat archives for akkadotnet/akka.net
I'm curious to know what indexing patterns people are using for persistent, remembered, sharded entities, when you need to lookup/address them by something other than the entity ID. Since shards can migrate between nodes, there's always a chance that a shard is currently "offline", so broadcasting/aggregating cant' always be consistent (i.e. while a shard is starting up on a node and loading all entities, those entities won't respond to the broadcast). Consider you have an entity called Contact, with it's ContactID, and you want to find all contacts with a specific phone number. You could of course map the index in a SQL table or something, and do the lookup there. But I'd like to avoid a database roundtrip if possible. Currently I'm using a secondary sharded entity whose entity ID is the "indexed" field, that does nothing other than rewrap the message with the now-known actual EntityID and forward it to its counterpart. It works well, but if you index 4-5 fields, for 100K entities, then you suddenly have 500K-600K entities that a cluster needs to fetch from the event journal on startup (instead of just the 100K), which slows down the startup significantly (lots of DB roundtrips). I've experimented with a cluster singleton that keeps track of indexes, and whenever entities are recovered/altered, they notify the singleton. It works great when the cluster is up and running, and it's fast, but when booting up, lookups return false negatives because the shard hasn't loaded yet and the entities haven't registered. So, I'm curious to know what solutions other people have found for this type of scenario. Are all the cool kids using doing this outside of Akka with SQL tables or similar?
I also considered using singleton with the broadcast/aggregate pattern against the entities, and hook into the cluster node and sharding lifecycle messages to keep track of when "partitions" are online or offline, and buffer broadcasting whenever one of the shards is offline, but that hits pretty hard against "availability" metric.