[quote]The server should be scalable, I guess the kafka or some other message broker should be used,[/quote]
I love Kafka dearly for bulk data ingest, but that probably isn't the right technology choice for a real-time game.
Real-time games use direct communication with the game server, which keeps all the game state in RAM. If you want to play in a browser, you will likely use Websockets for the communication; native games will use either raw TCP streams or, more likely for realtime, UDP messaging, using some custom protocol.
So, very briefly, for your goals:
1. pick a server technology that has the performance and connectivity characteristics you're interested in – node.js/ws, C++/websocketpp, Erlang/cowboy … whatever works for you!
2. build a server process that can receive, process, update, and mirror out gameplay events for 50-100 users. this server might in turn use a REST application server for its persistence needs, or it might talk straight to a database
3. build a simple instance manager that can spin up more server process instances when more people are online, and matchmake people to existing instances as appropriate
The game server will typically receive some ticket/token from a connecting player, use this ticket/token to look up actual player stats, and then instantiate the player in the game world. Whenever significant events happen (death, leveling up, trade, etc) this server will checkpoint the state of the player to persistent storage, but it's generally not possible to keep checkpointing every player every tick. Occasionally checkpointing, say, every 5 minutes, is fairly common, though.
Good luck with your game!