Periodic Batch Refresh Model
For SystemA providing data to SystemB: SystemA periodically exports a dump of some form containing the data SystemB requires. SystemB periodically imports the data in the exported dump. The import operation typically entirely overrides pre-existing data in SystemB's repository.
Periodic Batch Refresh Model.pdf
Exemplars:
Periodic Differential Refresh Model
For SystemA providing data to SystemB: SystemA periodically exports a dump of some form containing the data required by SystemB. A comparator retains state (usually in the form of the most recent prior SystemA export image) and computes a (hopefully minimized) set of changes represented in the SystemA extract, and delivers only those changes to SystemB. SystemB imports the changes, applying them to its repository to make it consistent with SystemA's new state.
Periodic Differential Refresh Model.pdf
Exemplars:
Changelog Consumption Model
For SystemA providing data to SystemB: SystemA continuously records changes made to its repository in some form of changelog. SystemB either continuously or periodically monitors SystemA's changelog for previously unprocessed changes, applying them in time-order to its repository to maintain consistency with SystemA's state.
Changelog Consumption Model.pdf
Exemplars:
Event-Driven API Model
For SystemA providing data to SystemB: SystemA establishes callbacks (typically in the form of database triggers) such that typical CRUD operations invoke callback routines that implement direct "push" of updates to SystemB via an update (and possibly a read) API exposed by SystemB. SystemA may, at its discretion, filter or modify the content of operations via its internal callback routines. The API exposed by SystemB in this case may be unique to SystemB (eg., a proprietary application-specific API) or may be a standard interface (eg., SCIM, SPML, etc.), and could be shared by other consumer systems.
Exemplars:
Messaging Bus Model
For SystemA providing data to SystemB: SystemA constructs and delivers to a messaging service (which may take various forms) whenever the state of its data repository changes in a fashion that produces a new internally-consistent state messages indicating the transactions applied to its data repository. SystemB, registered with the messaging service, receives the messages and reproduces the changes indicated to maintain consistency between its data repository and SystemA's.
Exemplars: