I'm currently trying to wrap my head around a suitable server architecture for a mobile tower defense game, which is verified on the server side. I've tried to analyze some apps from the app store, but reading the binary protocol is kind of hard.

Anyways, most of these games have the following in common:

1. You can upgrade characters / towers beforehand
2. Optional: you choose what you bring into the battle (deck)
3. You select the mission
4. You start, place towers, upgrade them ingame etc (there is NO internet connection require during the whole battle)
5. You finish and get rewards (internet connection required again).

Almost all of them seem to use HTTPS apis.

Question is: Are there any books / references for such an architecture? I'm guessing that I'll have to replay the whole battle on the server for point 5, so I need to send all the user's commands to the server after the battle is done.

Every game server must be informed of the characters attributes, so for the replay the must queue the (huge) database server for these attributes of the towers the player put into battle, right? It isn't sufficient to "hardcode" the gameserver, since whenever a player upgrades e.g. attack damage, the master server reduces resources and increases the unit's damage. So it's kind of dynamic.

I also need to send the wave data (5 units of type x on timestamp y) right when the mission is started, correct?

I also thought about microservices (Unit service, Resource (Gold, other currency) Service, Mission Service) but there would be a lot of roundtrips for every replay. Ask the mission service for the wave information, ask the unit server for unit stats, verify, send response. These are a lot of internal http requests.

I found a lot of papers on FPS games, but really not any good one about such a game. Any hints? Are my assumptions correct?

The amount of interactions during a game are tiny. The CPU used for simulating a typical tower defense is also tiny. Collecting everything the player did and re-running it on the server is totally practical for these games.

Yes, you need a database that stores the attributes of the player. This doesn't need to be "huge" -- a single MySQL server can probably serve 20,000 simultaneous active players with this model, and if you get more than that (success!) then you can trivially shard the database horizontally.

Sending wave data is only needed if the waves/levels aren't pre-defined in the download of the game.

Microservices that would keep "gold" separate from "resources" would be more like picoservices ? For your game, it sounds about right to have the "key" be the player ID, and the "data" to be a dump of the player state, in JSON or XML or whatever seems convenient to you. The one thing to watch out for is if you want advanced game analytics; if you store the player data as a blob, you can't efficiently run queries like "find me all players who have played in the last 7 days and have > 1000 unspent gold." (That can be hooked up as an analytics database later, if you want.)

The database schema you need for a player could literally just be a key/value store (like Redis or Cassandra or newly open-sourced FoundationDB) or it could be a single row-per-player in SQL:

create table players(
email varchar(255) primary key,
device_id varchar(255) not null,
hashed_password varchar(255) not null,
signup_date timestamp not null,
email_verify_date timestamp,
player_data text not null
);