After writing the question i'm wondering if i should just implement some simple caching in the entities that need the data and refresh every minute or something similar.

> I'd like a kind of primary/replica setup. I'm a little concerned about the single threading in a single instance of the entity. The performance per se is rarely a problem. A single thread is surprisingly powerful, and for CPU heavy work, you could always run computations on threadpool with

Task.Run()

. However, as you say, there is always messaging, processing and sometimes network latency in the read access if implemented over MetaMessages / EntityAsk. It really depends on use case if this adds up or not but in some cases we indeed avoid the latency with a primary/replica pattern which we call Manager/Proxy. If you want to implement this, check out

LiveOpsTimelineProxyActor

. The implementations is roughly as: * LiveOpsTimelineManager is a persisted entity that maintains state. State can be mutated by LiveOps dashboard. Manager is a singleton. * A single ProxyActor lives on every node. * ProxyActor subscribes to the manager on start and updates a

ActiveLiveOpsEventState

global variable. * When manager state is changed, manager informs Proxies, and Proxies update the global variable. * All consumers can read the current data from

LiveOpsTimelineProxyActor.ActiveLiveOpsEventState

. * (To read the data, you need the

AtomicValueSubscriber

and remember to call Update() before accessing Current) > Should implement some simple caching in the entities that need the data? That is possible approach too. However, if the caching is needed, I would personally prefer the Proxy pattern so the cached is updated almost immediately instead of waiting for the stale data to invalidate.

Generally I'd start with the simplest solution of using a singleton entity and EntityAsking from it and see how long it scales. If latencies start becoming an issue, adding a cache or changing the implementation to fetch from a Proxy should be relatively simple update.