I am working on improving the backend design for a video game. The game is live and working fine, but we want to improve various things. As a video game studio, we often do events which sometimes need tinkering with whilst the event is live - we would love to be able to do these changes seamlessly without having to force an update on players.
Our current backend uses various hardcoded values that our endpoints use. This means if we ever want to change an endpoint's behaviour we have to re-deploy. For instance, if we decide that a certain online-store item needs to point to something else we would need to change the id that is referenced on the endpoint. This is cumbersome and not ideal; we want a more dynamic way of changing configs.
The general idea we had is that we store these properties in a file on S3 / a CDN and the client and the backend fetch these periodically. There are issues with this approach when it comes to ensuring that both the backend and the client use the same configuration.
Edited solutions for clarity
Create an API that allows the source of the "truthiest" file to speak to the server. Push this new file to the server's cache whenever there is a change. Then, whenever the client talks to the server, check the client's file version/hash and compare it to what we have. If it matches, proceed, else we either 1) force the client to update, 2) tell the client to update manually (meaning we deny it access until then) or 3) have a version leeway that will give enough time for the client to update, in theory.
- avoids roundway trips between server and file provider
- not sure what solution is best for synchronising (1, 2 or 3)
- more work required to build API etc...
Solution B) Both the client and the server make calls periodically to see if there is a new config. When the client speaks to the server and the versions do not match, we have the 3 options again, only this time the server has to make calls to the storage (the truthiest source) to check which version is the correct one.
- less work than Solution A
- less reliable, too many points of weakness
- too many round-trips between server-storage and client-storage.
Note on storage There are problems with both S3 and a CDN. S3 isn't always honest - it can sometimes return older data - it is not a single source of truth. A CDN is useful as clients will have download this data for their specific language, but redistributing each new version can take time, which is why we may need a leeway.
This is a brief overview of the ideas we had. There are caveats that may or may not have been outlined but we are looking to find how this kind of thing is typically handled.