Using a database to communicate client and server - what's the catch?

Question

Game development

Let's imagine that we have a multiplayer (two-player) game with a very slow pace: a turn, where the turn consists of a common order phase for both players and an execution phase (in which players simply watch how things unfold). Accordingly, there is no real time here and a delay of a second or two is not critical.

There was an idea to unify and simplify the work to make communication between clients and the server through a database like the same Redis. Clients write a package with orders into it, then take the package with the results of the move for visualization (all calculations are completely performed on the server and each client receives only the data that it must display).

The server, accordingly, spins two cycles: one takes packets with orders from the database and sends them to the corresponding GameObject instance, and the second one looks at the local result queue (where GameObjects put the calculation results) and writes them to the database. Thus, the client and server parts are completely decoupled from each other, to the point that it will be possible to change the server at any time if necessary (by dropping the state of the games into the same database) and the clients will not even notice it.

And now, in fact, the question is: what's the catch? I'm still only dealing with the issue (this is my very leisurely pet-project), but in all the articles that I've seen, data exchange is done on sockets. Tell me what I'm missing?

Answer 1

I didn’t quite understand how the client should interact with the database:
- If through some kind of CRUD service, then why not - many people do this.
- If you mean a direct connection to the database, then there will be problems with security, differentiation of access rights, load balancing. The DB is not guided by such use.
If I understand correctly, then what is needed here is not a database, but a message queue (which can work on top of the database, or maybe use its own storages).
You make a service to which the client connects. The service, at the command of the clients, sends messages to the queue and forwards the responses received from the queue back. The game logic sits on the other side, consumes messages from the queue, does the magic, and sends the results back.
There are many implementations of queues for every taste, including something in Redis.
The connection of the client with the service can not be kept, but then it will have to be polled periodically, which will add load. There is a dilemma here: either bother with maintaining many connections, or with increased load and delays. Practice shows that the interaction between the client and the server over time acquires auxiliary logic, so keeping a constant connection can be more profitable in the long run.