Disclaimer: I am an independent game developer and studio owner making games in Rust. My opinions below are informed by 2 decades in indie game dev and web-based SaaS experience. They are my own opinions and not necessarily a reflection of the state of the art on the subject matter.
Axum is a very appealing HTTP server, and seems like a good choice to start with. It's kinda sorta "NodeJS Express-flavored" or "Python Flask-flavored", which a lot of devs will appreciate.
For the game, bevy is a good option. It contains a lot of foundational tools that you will want as a game dev. But even with smaller projects, it doesn't really have everything you will need out of the box. For instance, the collision detection included in the base crate set is rudimentary. Many will likely try using a 2D physics engine, but it really only makes sense to use a physics engine for physical interactions. (The kinds of things you see in a physics sandbox where objects collide and interact in a chaotic but realistic manner!) For what is essentially a digital board game, you might be perfectly served by the simple built-in sprite collision.
Macroquad does a lot for the I/O aspect of a game (video, audio, input) but almost all of the pieces of a functional "game engine" are either marked experimental or are entirely missing. Even something as basic as a state machine to manage various states of gameplay (e.g. scene management):
+-----------------------------------+
| |
V |
[Loading] --> [Intro] --> [Title screen] --> [Start game] --> [End game]
^ ^ ^ |
| | | +--> [Pause game]
| | | | ^
| +------------+-----------+ |
| V
+--> [Options Menu] [In-game options]
^
|
+--> [Display Submenu]
|
+--> [Audio Submenu]
And transitions between them (cross fades and so on). This diagram is simplified. There are probably a lot of other states to consider, like a character select screen, maybe a login screen for associating an account ID or whatever you will be using for storing game state in your database (even if it's just a high-score table).
As well as the aforementioned collision detection there are animation state machines, tile map loading, sprite atlases, and dozens of utilities like pathfinding, ray casting, tweens aka easings, particle emitters, etc. etc. The list is practically endless. But these are things that you may want to use at some point. Even still, plenty of games have been made with macroquad.
For multiplayer, there is still a lot of ongoing research to deal with synchronization issues and cheating. For the former, a protocol-based solution like rollback networking could do the trick. ggrs and backroll fall into this category. For the latter, good old central authority servers are still the most common solution, but peer-to-peer models also exist (cf. RACS and Cheat-Proof Playout for Centralized and Distributed Online Games). The benefit of a peer-to-peer model is that you don't have to run a copy of the game on a server in a headless mode to compare against what the players say they are doing.
I think I've given a decent number of items that you would need to learn for making a game. But for a web service you will have a lot of other considerations. What does your database look like? Is the app a "SPA" or just a single HTML document with the game embedded in it and "no-frills", or is it somewhere in between? What does your web stack look like; is it all Rust and WASM (maybe yew?) or is built on React or Angular or Vue? Are you going to manage the servers in Digital Ocean, or AWS, or GCE? Maybe you want some redundancy, and you want to think about Kubernetes or at least Docker Swarm?
Or, to paraphrase Richard Feynman:
Nearly everything is really interesting if you go into it deeply enough.
And now for some real advice. For your first project, do something REALLY small. Throw out the online multiplayer. Throw out the web app and all of its infrastructure. Focus on creating a little game in 1 month. Not a year. Just a month. Learn how to make a game. Once you've done that, then learn how to make a web app in 1 month. Something simple again, but still relevant to your actual goal; it has a login page, it has a database where users can edit their profile and view other profiles. Stuff like that. Learn how to manage servers and define database schemas and create-and-restore backups!
Then make a new game with some multiplayer functionality. It doesn't need a web app at this stage. Just get something working where you can connect to a hosting player's server and interact in the game. 1 month. Maybe 2. 
If you are lucky, the design of your first game might be salvageable to add multiplayer to it. But in all likelihood, it won't be a good fit because you just learned how to make your first game. You will have made all kinds of mistakes, and some of those mistakes will still be there, baked in. Start fresh for the multiplayer game. Apply what you learned in the first one and make new mistakes!
Finally, after you have taught yourself all of the necessary pieces in isolation, put it all together and spend the rest of the year making your web app, service, and multiplayer game. Again, your first three projects probably will not be reusable for the whole thing. You'll be better off rewriting it and using what you learned from the initial experiments.