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

enter image description here

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 players and 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

  1. create separate service which will be a single endpoint to RDB - basically only this service will have access to players and levels data.
  2. 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).
  3. 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?

  • It's not entirely clear to me why you have split your application up this way. Can you explain better what the point of the design is? – Paul Mar 6 at 15:31
  • @Paul I updated the question with detailed description – lapots Mar 6 at 18:43
up vote 1 down vote accepted

So it seems to me that unless you have a good reason to have separate databases, you should just have one database. It looks from your diagram like the Rules engine is essentially getting read only access while the UI gets read/write.

If that's true, then you could either share the same DB or else have the UI-backed one be the master and the Rules one being a slave to it. Let the DB handle replication, since it's built to do that.

  • 1
    Or simply swap in a test database during testing. – Robert Harvey Mar 6 at 19:23
  • Yeah, I didn't pick up the fact that one was a test DB. – Paul Mar 6 at 21:09
  • Oh I see. But still it might be good to do some caching in rule engine? – lapots Mar 7 at 10:58
  • 1
    That’s an optimization you can make if you need it. There isn’t enough information here to be able to answer definitively about that, and I’m generally in favor of only adding complexity when you are certain it’s necessary, not just when you think it might be. – Paul Mar 7 at 13:15

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.