A) I’m having a little difficulty understanding exactly what you are asking in this question. If I’m not answering the question you meant to ask let me know.
First I should disambiguate between chunks and workers, in case that is a point of confusion. Workers are the things that are doing the computation and simulation, and can have knowledge of entities across many chunks. Chunks are square sections of your world, that are the smallest amount of area you can check out any any given time. In a certain sense, if you think of the world as a hashtable, the chunk would be the key and entities would be the values. If your worker is checking out an entity, it will also check out all other entities in the same chunk.
As for the radius of interest moving with the player. Yes this is how it works. Again if we assume that your client has authority over some component on the player entity, as the player moves that radius will define a circle around the player. The client will then be granted read access to any entities in any chunk that is contained within that circle. Often the chunk size is much smaller than the interest radius, so a client will have many chunks in it’s checkout radius at any given time.
B) From a timeline side, we’re happy to say that we have a lot of runway, especially since last year’s $502 million investment from SoftBank. In addition to that, there are an increasing number of important studios that we have partnered with to make games. We would hope that this demonstrates our reliability as a service provider. However, if you have more serious concerns about this, you can talk to us privately and we can go through what backup plans that there are in place.
C) Here are the docs for the point of interest loadbalancer. All that you need to do is write your worker code once, and then spatial and the loadbalancer take care of spinning up copies of your worker and placing them where you want them to be. Honestly the easiest way to understand this is to try it out yourself. If you haven’t already, check out the pirates tutorial. If you want to see what it’s like to configure the workers, then try modifying how many workers spawn in the default_launch.json file and then use the SpatialOS inspector tool to see what your changes did.
Here’s an example of what that might look like with two workers. It’s a bit complicated with the overlap here. Essentially the solid areas are where each worker has authority, whereas the areas with the dotted line shows the boundaries of the worker’s read access (which is defined by it’s entity interest radius). You can also see that in the areas where there are no entities, no worker is authoritative, and this will change automatically as entities move around. Furthermore on your final question, these workers are just copies of each other, that spatial is automatically starts up when you launch your deployment.