Processing still seems locally coherent, to me. A single process needs real consistency but all of the other federated processes could probably get away with “eventual consistency”.
…unfortunately with a single-server (SQL server) star architecture everyone contends with everyone else. And then they still should find a way to share changes even though the data already has those changes.
A true federated ES might allow localized data storage and simply send out cache invalidation messages to peers. I suppose they could still share a centralized DB but it should be something enterprise-level like Postgres.
I always envisioned a federated ES to be federated along system boundaries, though, and not anything spatially aware… but ultimately it shouldn’t matter too much. The thing you’d want distributed most is physics and it should be easy enough to split on zones… which could still be local data.
For true MMO style federation, normally you’d have a server (or block of servers) handle a specific area of the world/universe. Things can be very localized in that case.
Anyway, this is all more complicated than just smacking hackable remote support into the client-facing RemoteEntityData. That might have been simple but it’s just about the worst architecture to use for federation and won’t scale well at all.