> (Hm. What if you wrote a back end which, instead of needing multiple "cloud" machines, ran on a single huge Amazon AWS instance, like the one with 128 CPUs. That's an easier problem than coordinating it over the network. You might not be able to support a planet sized world, but you could support large islands you have to teleport between.)
You can get really big systems these days; scaling up before scaling out really helps with coordination problems. But scaling up your servers also makes redundancy and data retention harder. And, when you end up running single (or paired) systems that are the biggest you can get, economics are often lined up against you -- motherboards and processors for 4-socket systems cost way more than for 2-socket systems, and they're updated at a slower pace. If you can make a system to allow seamlessly transitioning region boundaries across server nodes, that should work fine with a single node server, but also enable you to use less expensive nodes; and in cloudy situations, could enable ramping capacity to match usage in real time.
You can get really big systems these days; scaling up before scaling out really helps with coordination problems. But scaling up your servers also makes redundancy and data retention harder. And, when you end up running single (or paired) systems that are the biggest you can get, economics are often lined up against you -- motherboards and processors for 4-socket systems cost way more than for 2-socket systems, and they're updated at a slower pace. If you can make a system to allow seamlessly transitioning region boundaries across server nodes, that should work fine with a single node server, but also enable you to use less expensive nodes; and in cloudy situations, could enable ramping capacity to match usage in real time.