We're starting to look at implementing an ESB / Microservices architecture. I (think) I know about the concepts, but there's one thing I don't seem to be able to get a good idea about: data replication / synchronisation.
Creating an event for each and every table (maybe even multiple (create,update,delete)) seems like overkill to me, if it's just to synchronize data. Wouldn't an ETL / SQL Replication solution be much easier, in cases where no business logic will be exectute, as it's just to update the local cache/db of the server?
What strategies would you advise?
Simple example, we have an application that manages all product data, we want to build an API (Web Service) that is going to serve a Mobile App that will display that data.
There are several options:
- API directly accesses the database
- API has a local database that's being kept up to date using ESB messages
- API has a local database that's being kept up to date using some replication tool
- API has a local database that's updated once a day using a batch operation.
In my opinion the reason to use messages would be to further uncouple the systems as the database structure behind it can be changed without affecting the system in that scenario. For all other means and purposes 3/4 seem much let complex, which in my opionion meets the KISS principle.
What would you advice? Where can I get some sort of flowchart/decision tree example on what alternative to use when?