I am not familiar with Brawl Stars or Clash Royale, however here are my thoughts:
In general, for MMOs, you want to have a scale-able backend. You can achieve that using stateless services and task queues. For example, you'd separate the login service from the rest and it probably would not need a lot of resources. On the other hand, you'd create separate match instances for players, which have to do the game simulation, and require a lot of resources. You'd scale by getting one instance per match, for example, to keep them all performant. However, the exact scaling and how to separate the backend depends entirely on the game.
As for the tech, anything which is able to use network sockets will work, including NodeJS, however I'd decide the language on what the platform can do best. NodeJS is very easy to develop and has an insane I/O performance, however it sucks big at doing number crunching. I'd use NodeJS for anything which has to pass messages and hold many connections, however use something different for the actual simulation. I'd go with Rust for that. Big companies will have all of that run on their dedicated servers, however for smaller games, serverless should do the job pretty well. Maybe a combination of both, depending on the game, player count and budget...
is a RTS game. First thoughts: The backend does not need to respond quickly. It does not matter if a user has to wait 1ms or 10ms or even 100ms to see the next move. Also, there is not much going on in terms of game simulation. All the server needs is the state of each player, and then do a small calculation on each move. The connection could be done using a server or even RTC (without a server), though a server always provides additional security against users, especially in an MMO.
I'd create one service for authentication and match-making, one stateless service for game logic and database instances for player states. There'd be a match-front-end, which keeps connections to the players via a socket and communicates with a message queue. A player would then send a player-id with an action. The match-front-end would look up the state-db used and add a task to calculate the game into the message queue. Some game server would fetch the message, look up the states, add the action to the states, update the db and then send a message with delta-update to the match front-end, which in turn sends the updates to the players in a match.
Scaling is simple. A player connects to any authentication service (behind a load-balancer), starts a match and switches to one common match-front-end with all other players in a match. For each player, a state is created in a database. Then the player would perform an action, which is sent to the match-front-end, is added to the MQ, hits a game server, and then a delta is sent back via MQ and match-front-end to all players. The game clients just have to apply the delta to their states to update the game. If more players come in and the servers are starting to have trouble, just add more servers.
is an action game. Let's take Brawl Stars as comparison. In CR, you will have to simulate a game world and react to players' inputs very quickly, ideally without latency. However, the servers must not take a lot of time to verify actions and update other players. So, instead of using an MQ, usually players are directly connected to a service, which runs the match. At least that's what I'd do. Each match gets its own service instance, to keep things simple and scale-able. The primary task: take input from one player and send it to all other players. In the background, the server should do checks, like running physics simulation and check state changes against certain boundaries to detect cheating. The server will also have to run some game code in order to find out about new entities which have to be created. For example, if a player has a certain score, the game might conclude, so the server will have to make sure the match terminates.
In addition to such a simple setup, modern MMOs include different techniques to update player states before they even receive an action from a player. For example, by studying a player's behavior, they can try to predict what will happen next, and once a player sends an action (or not...) update the other players to reflect reality.