Post date: Jul 26, 2017 7:44:32 AM
Each MicroService instance should have it's own database instance (possibly on a shared Database Server).
This implies that:
Cloning Databases across MicroService versions should be relatively easy.
Duplicated data needs to be automatically synchronized across different classes of Database.
Databases should be easy to scale, to keep pace with the MicroService it serves.
These are not easy requirements to fulfill.
A database cloning strategy I've used in the past stores database changes as a sequence of patches (recorded in a table), including:
Creating Database schema i.e. Tables, Columns, Foreign Keys, Indexes etc
Translating Data as required by schema changes
The changes can be placed under source control and merged. A branch naming convention is required to support this:
Each version of the MicroService Database is developed on a new branch
Branch names are incremental release numbers e.g. 00A00300F = [10,3,15]
A MicroService version refers to just one database version.
Each database change is numbered using the branch number and a change index maintained for each branch e.g. 00A00300F0F3
NOTE: This is the key to keeping the order of application
This ensures that changes made to a previous version of a database will be applied to a database before changes to the next database.
As with all merge operations, merge conflicts are possible;
integration tests should highlight any database merge issues.
Database upgrades in an earlier database should not conflict with later database versions (otherwise a full database deploy will be required to upgrade a later version)
Automated merges can reduce the overheads of merge conflicts.
Upgrading or creating a new DB instance is relatively simple;
Clone the database, as recommended by the DB system provider.
Run the Queue of the new version against the cloned database.