Dear @CIG_ChadMcKinney, After looking at this week's roadmap update, I tried to wrap my head around the underlying technology. Below I have noted my understanding of each technology including how they relate to each other. Could you please give me feedback on whether I got this right - and, if not, correct it briefly? That would be great and incredibly helpful for overall understanding! Shard: A fixed delimited part of the game world (global/territorial (US, EU,..)), which contains data sets as an image of the PersistenceDB. A shard is computed by a mesh of servers (DGS - Dedicated Game Servers) that dynamically scale horizontally depending on the shard's workload. The servers themselves do not have their own DBs. Each of these "physical servers" can take on one or more shards, though it's open which target scenario CIG is aiming for (a global shard vs. regional shards - does "region" mean ingame parcels or EU, USA, Australia...?). Shards, however, are by definition CIG static. The shard is ergo provided with fixed parameters and boundaries, which brings transaction security if later players move from one shard to the next (I didn't quite understand, but you wrote about a "rare" case). The shard has to be mirrored into the global persistenceDB. This is done by the Replicant Hybrid. Matchmaking: Communicates with the shard manager and "matches" a shard to the surrounding (replicated?) shards. Then the shard is added to the DGS mesh so that hybrid and DGS have the same data and players can join the shard and interact with each other. EntityGraph (formerly iCache): intermediate storage layer between the server mesh and the backend DBs (including PersistenceDB and EntityGraphDB). EntityGraph Seeding: A shard is seeded, i.e. according to a key the world-specific entities are assigned to the shard, initialized and spawned. Diffusion: AI-based data management system that acts between backend DBs and EntityGraph and that feeds data to the EntityGraph using the push principle. DataCore Deserializer: A C++ Star Engine service as API between backend and Diffusion Replicant Hybrid (Hybrid): presumably a hybrid of replication layer and shard dataset (live environment) for the purpose of management, simulation and resilience. The Replicant Hybrid mirrors a shard to store state in the replication layer. This offloads the DGS and provides resilience. Technically, the Replicant Hybrid is a multi-layer/multi-tier architecture. Data accesses from the Replicant are presumably dynamic, both (1) via the cache structure (EntityGraph) and (2)directly to the backend database, in order to perform powerful batch jobs or similar. Shard Manager: Is part of the Hybrid and responsible for creating a shard in the EntityGraph Database and ensuring proper seeding (EntityGraph Seeding). Atlas: Game region management and data communication - splits the game into n manageable territories (regions), which are then transferred from Atlas to the Replicant Hybrid. Blackboard service: presumably a cache where different services can cache some values that don't belong to any particular service now. If you could briefly tell me if I have understood correctly - or correct/explain if necessary - that would be super, so I could pass it on to the German community accordingly. Thank you, many greetings and tomorrow a good start of the week!