Fantastic explanation Clive thank you. If I may ask another question, recently we’ve seen a statement from CR stating that you are having performance issues with the entity graph database on live. Based on the example we saw, entities and whole object containers transitioning between zones are also stored in the same database CR was speaking about to maintain persistence correct?. Assuming that’s the case, when the example is scaled are you experiencing the same performance issues we’re seeing on live? I imagine a large ship moving from zone to zone is a large update in the graph? The example showed how the replication layer works, however I’m concerned that the entity graph may hold it back. After all, a system is only ever as fast as its slowest part. Thanks for any insight you can provide.

At present the performance issues CR was talking about only affect operations interacting with the Global database. The Replication Layer only interacts with the database for a single Shard so currently isn’t affected. We use the same database engine for both the Global database and all our Shard databases so in theory shards could suffer the same issue but the difference is that the Global database (which holds all items in all inventories) is much larger than the individual Shard databases tend to be and this particular issue only shows up at this larger scale. So for the immediate future the Replication Layer should not be affected. Our Online Services Team and DevOps continue to work closely with our database vendor to monitor the problem and ensure it gets fixed once and for all. Hopefully this issue will be an unpleasant memory by the time Shard databases scale to the same level where it can occur