System Synchronisation

There will be built in the ability to have multiple Butr systems be able to synchronise data between the systems. This will allow organisations with multiple brands to have one Butr instance for each brand, and for example if they are sharing the same stock then they would be able to take stock or return stock between the systems.

You could also use the System Synchronisation feature to have geographically disperse systems which would keep themselves up-to date. This would allow fast access to the system for the local users of the instance, and would reduce the bandwidth of going to the central system all the time. This would most likely be implemented in the Gateway layer. Essentially messages would be queued off to remote systems once they had been verified.

The Javascript object would be serialised with other data for sending to the remote system. It would be hoped the same messages could be used for replication as they would for API calls. This would reduce the number of messages.

For bonus points this would be implemented as a multi-master approach. Every record will have a _table_uuid which will be guaranteed unique. The systems will communicate using these _table_uuid values rather than the internal _table_id. The _table_uuid will be a Universally Unique Identifier (UUID), whereas the _table_id is a bigint.

The common fields would be the _table_uuid, and system node (from global configuration) as this would uniquely tie the records together. This would mean that the internal identifiers could be different and it would not cause problems as long as the internal identifiers remained consistent.