Question directed to devs who know a bit about setting up middle sized architecture.

Prestory: Joined into development of a middle sized online game. Figured they created a monolith over the last 6 years up to a point where nothing works properly and nothing can be changed without wrecking the whole system. Figured a monolithic approach isn't such a great idea.

Current Situation: In a different, same scale online game development team, game itself working but team is struggling with architecture.
My job is to come up with an approach on how to set up masterserver/matchmaking/database etc. Reading through various articles about common principles (SOLID etc.), i figured that a microservice+event-/servicebus architecture may work for that kind of project.

The idea would be to have a global interface in which microservices can be hooked. So a client registers to a client handler on startup, then starts to queue for a game, the client handler throws an event on the bus to register the user to matchmaking. The matchmaker happens to listen to those events (Observer Pattern) and adds him to matchmaking, when a match is found it throws an event on the bus to connect the user to the server, etc. One can easily imagine a banhandler throwing in a veto to cancel such an action, metrics and logging is fairly simple to add (just another service listening to all events), additionally Continuous Delivery, FRP and such are also beneficial advantages and it is said to scale well.

The question is, would you do the same, is there maybe something i might be overlooking? Do you have better ideas?
Keep in mind that we are not too experienced and are bound to different languages (python, C++ and java mostly) and are a small (4 Devs) Team with different strengths.

Thank you for your feedback and criticism!