General way to handle this is to allow multiple game servers to be spun up, and whenever a new game is started, one is chosen and the client is told to connect to that server. You can then add and remove game servers as necessary to scale horizontally, essentially limited by only by hardware/bandwidth capacities.
Scaling up the login servers can be done by using round-robin load-balancing on your servers, which can be achieved at the DNS level, or via a hardware load balancer (generally not cheap, though some data centers offer use of a shared load balancer for a price). The same can be done with the match making servers.
You can also deal with this per region. That is, your customers in China might be using a different set of servers in a Chinese data center while your customers in North America might be using a set of servers in a data center there. Or if NA is where most of your customers are, you can split up the data centers between the east and west halves of the continent.
Things get tricky when it comes to sharing data between your servers. In these cases, it is generally better to have a middle layer between the main game/logic servers and the backend storage. That is, don't have your game servers access a database to look up player information. Instead, create an internal API (using REST over HTTP, or an AMPQ infrastructure, or what have you) that servers use to communicate with backend services. The advantage of this approach is that it makes physically distributing your services easier. You might want those match making and game servers split between China and NA, but you might want all account information to be centralized so players in each region can friend each other and start direct matches with each other (of course one of the two players will be using a non-ideal game server for their location, but no way around that). With an API, you can have your Chinese data center game servers talk to a local API proxy that caches requests made to the "authoritative" servers in NA, allowing distributed operation with good horizontal scalability and a single primary data store for user accounts.
Keep in mind that you'll want to limit that as much as possible to infrequently changing data, since you'll need to do all writes to the primary data center to avoid collisions. That is, you can't share user accounts between a NA and a Chinese datacenter is both can create accounts locally, since two users might try to create a user account with the same name in both regions. Since you'll be forced to use one data center as the authoritative master for this data, that means creating accounts in other regions will be a tad bit slower. Account creation is generally not something that needs fast response times, so that's not a huge deal; if you're trying to track play stats for every move in your game, though, it might become an issue. For cases like that, you'll want to aim towards a data design that allows merging data later in bulk, rather than needing to keep a real-time data set in an authoritative server.
All that said, you probably don't need to worry too much. A simple turn-based board game style of thing is not going to be particularly data intensive, and your odds of getting lucky and being successful enough to have so many users that one server can't handle the load is pretty small.
