Which database to choose for mobile strategy?

Question

Database

At the moment there is a server with a monolithic architecture, which is divided into pseudo-services.
The general service (OS) is engaged in all social work (clans, matching, chats). It runs in a single instance.
Private services (PS) hold tcp connections with clients and execute business logic that concerns only them. We can run several of them. Load dependent.
There are also combat services (BS), but they have nothing to do with the database at all.
By the way, there is only one database and it is MySQL. Both general and private services go to her.
The problem is that the OS + ES cluster is deployed in one region - Europe, so players from America or Asia are experiencing problems connecting. Even if they established a connection, the ping to the emergency leaves much to be desired. We cannot deploy independent clusters, as there is a requirement to match players from all over the world. Keeping one database in Europe, and launching emergency situations + operating systems in three regions is also not comme il faut. And with the start of a new project, another condition was added: if one region collapses, then the player must be able to connect to another region without losing data.
It turns out that we need distributed storage, with replication between nodes and the ability to write to each node. Maybe this opinion is erroneous and some simpler scheme will do? Enlighten me please
Another follow up question. Is it possible to use distributed caches (such as Apache Ignite, Geode) without using a database layer? And what is the risk? does anyone do this in production?

Answer 1

You have several problems. The first with latency, the second with source of truth.
The first is solved through CDN and replication of instances with logic. Guaranteed to come to queues and asynchronous data processing with event consistency.
By databases - either completely change the logic of the application and communication, or use distributed databases, such as AWS Aurora and AWS DynamoDB. By themselves, they are regional, but there are interesting features that allow you to display them all over the world.
I must say right away - there will be collisions in any case

Answer 2

And what about the DB?
Use MySQL as before.
And to improve responsiveness, you need to optimize the game itself. This is done in different ways. Depends on the game. By the way, you didn't even say turn-based strategy or real-time. A lot depends on this too. If there is a real requirement to match players from all over the world , then first of all you need to fire the game designer.
As for distributed storage, there are tricky options when the data is stored on the user's device and the servers trust them. This removes the strict replication requirement, and even adds the ability to offload the servers themselves, but in return you will have to do a lot of so-called programming. arbitration system based on the "trust but verify" principle.

Answer 3

postgresql

players from America or Asia are having trouble connecting

pick one

if one region crashes, then the player should be able to connect to another region without losing data.

not realistic and not necessary. Do a duplication in another DC in the same region
Depending on the type of game and match, you can do hacks

Answer 4

Hello, you need tarantool , this is the best solution for your requests.
2 in 1 Cache and DB
Replication and Sharding ( see how easy it is to make a replica and sharding )
All operations are written to logs, nothing will be lost disk) Data consistency (no discrepancy with the database and cache) Built-in procedures (saving latency, no need to carry large amounts of data over the network) Transactions Secondary indexes Queues No cold start problem (data is always hot) There is a docker with an example
replicas
Of the minuses, there is no full-fledged GUI, only tarantool-admin , the main work is the console and scripts.
Telegram group