I've got two applications - one application is essentially a REST service, another app has UI that communicates with REST (uses it facilities).
The idea is that
rule engine is a service that can execute rules against the input - input is not neccessary
player data but some other (like
level specific, or
quest specific and so on). So I made it into a separate microservice. But as REST it has to validate the input - the input may come not only from UI application (that could provide its own checks) but from some REST client - so I decided to create a database for rule engine service (because microservices supposed to have its own storages) that would contain the data that allows to validate the input.
Sandbox application represent some kind of admin or sandbox where I may create
players, do some test runs like
level up and so on. It has its own database too because it is more or less reflect the final another application.
The schema looks like this
Sandbox UI application sends REST requests to Rule Engine Service with some data. Rule Engine Service validates the data against its own RDB1 (which contains the same data as RDB2 in sandbox - tables
levels are the same in both databases so they data should be consistent), does execution of rules and returns the response.
My problems is to choose the strategy how to synchronize both databases to keep it consistent (for now at startup I populate both databases with the same data). I see several approaches
- create separate service which will be a single endpoint to RDB - basically only this service will have access to
- use messaging system (use RDB2 as some kind of master database) and upon changes in RDB2 send the message and update RDB1 (or other databases) (leverage pub-sub model).
- use cache in REST application instead of database and use pub-sub model to update it.
What approach it would be better to use? Or are there some other ways?