@@ -308,18 +308,23 @@ In the next step we've to scale the databases. We've to divide this into two par
308
308
1 . First we want to scale the databases for reading purposes.
309
309
Since there should not be a concurrency problem in this application, we can add replicas for the MySQL and Redis stores.
310
310
2 . Then we want to scale the databases for writing purposes.
311
- __ Example for connect four__ : I've put much effort to allow scaling the Connect Four context properly.
312
- Because we use the CQRS pattern to decouple the queries that span multiple games,
313
- such as counting running games or listing open games, we can ignore this queries in this case.
314
- To fetch the command model we exclusively need a game id.
315
- With this in mind, we can leverage a technique called
311
+ __ Example for connect four__ : This context already can be scaled-out by
316
312
[ sharding] ( https://en.wikipedia.org/wiki/Shard_(database_architecture) )
317
- for this. The shard key is in our case the game id.
313
+ the database, since queries that span multiple games have been offloaded. How this is made possible is described
314
+ [ in this section] ( #connect-four ) .
315
+ Only the game id is needed for the execution of the command model,
316
+ which is why it's well suited for the sharding key.
317
+ Sharding is done at the application level, more specifically in the
318
+ [ repository] ( /src/ConnectFour/Port/Adapter/Persistence/Repository/DoctrineJsonGameRepository.php ) .
319
+ The application uses schema-based sharding and is aware of all existing logical shards,
320
+ while it's only aware of one physical connection. To actually forward queries to separate physical shards,
321
+ a proxy such as ProxySQL can be used. An example will be added with
322
+ [ #118 ] ( https://github.com/marein/php-gaming-website/issues/118 ) .
318
323
__ Example for chat__ : Currently there shouldn't be queries that span multiple chats.
319
324
To invoke a chat operation (either writing or reading) we exclusively need a chat id.
320
325
As in connect four context, we can use
321
326
[ sharding] ( https://en.wikipedia.org/wiki/Shard_(database_architecture) )
322
- for the chat context.
327
+ for the chat context, where the chat id is the sharding key .
323
328
324
329
You may have seen that all contexts uses only one MySQL and one Redis instance.
325
330
This could be different for the production environment depending on the scale.
0 commit comments