I'm not sure if I understand the first approach youIn the partitioned caches for each key there is a single partition that key belongs to. For any partition, there is exactly one node which owns that partition (this is the node which stores the primary copy of the partition), and transitively owns the entries with the keys belonging to the same partition. There is also a configurable number of backup copies of each partition (provided that there are enough cluster members for hosting each copy in a separate member, as each copy must reside on a different JVM; the copies also reside on different hosts if it is possible to lay them out so).
described. It might have to do with the fact that i
don't know about the concept of 'key owning' ;-)
I expect to receive different types of events, IFor non-persisted events a simple cache is enough, hosted by a cache service for which the event handler nodes are the storage-enabled nodes. A storage enabled-node for a partitioned cache service is a node which holds primary and backup copies of data. Nodes can also be storage-disabled in a partitioned cache service. These nodes can access the data in the partitioned cache but they don't store copies of them (therefore coming and going of these nodes don't incur loss or rebalancing of the data).
think that all three categories you mentioned are
Our platform starts with 10.000 registrations, 1.000I can't comment on this, as only you know what processing cost handling each event incurs and what hardware you have for it. Still, these numbers do not seem to be anything to be frightened about.
concurrent users each firing different all types of
events, 1 event per 10 seconds. The number of
registrations is expected to grow quickly in the near
future. The number of concurrent users will grow
relative to that, their event firing behaviour is
expected to stay constant.