Multi-Threading or Multi-Instance / Process in C#?

I have written a game server that is capable of hosting matches and multiplayer games. Each physical server can host multiple virtual game servers (essentially player sees it as multiple servers but it could be only running on one singular server) and is connected back to a master server for database and account management.

Here's the idea :

1. Multiple Instances would not communicate with each other, they only report back the master server (database, which runs on a totally different physical server) when a certain event occurs
2. Each server runs on one main thread for handling in-game events, and a thread pool (using async-await) for network service.
3. Certain Instances hold games (game mode) that may end in a few minutes, others may persist.
4. Stack overflow is quite impossible as no recursive calls occur in the code, only loops are involved in handling such issue.

The question is, which is the better design pattern for our project:

A. Multi-Process (Instances)

1. This would require a Manager that acts as the proxy between the Master server and the virtual servers. Since virtual servers have expected lifetime and that Master server is hosted on a different physical server, a manager program must be designed to persist and instantiate child game servers. (More programming and maintenance)

2. Less Prone to errors, if a child game server crashes, it wouldn't effect on other virtual game servers.

B. Multi-threading

1. Possibly less resource hogging. Since Thread pool and memory allocation are done by the same GC. A lot of freed and allocated resources can be reused without too much penalty. Also, the thread pool is shared throughout different instances.

2. The main thread acts as a management process and instantiates a new instance by creating a new task in the thread-pool.

3. Uses less socket = possible faster response time, InterProcess Communication and create a bunch of connections back to the main server meant more resources can be allocated to handle client requests.

Initially, this was written in C++, which is no doubt, (A) was the way to go, since any bugs presented in your code would have a high risk of crashing the whole process in the unmanaged realm of programming. Since no GC is present, the advantage of (B) seemed less attractive.

But since we have transferred to C# for higher production speed, it's a managed coding environment, which meant it's less prone to error and most exceptions can be caught and handled properly without crashing the program itself.