How it works...

Cloud-native systems are architected to evolve. Over time, the functional requirements will change and the technology options will improve. However, some changes are not incremental and/or do not support an immediate switch from one implementation to another. In these cases, it is necessary to have multiple versions of the same functionality running simultaneously. If these services produce data, then it is necessary to synchronize data changes between the services. This bi-directional synchronization will produce an infinite messaging loop if an appropriate latching mechanism is not employed.

This recipe builds on the database-first variant of the Event Sourcing pattern. A user of service one invokes the command function. The command function opens the latch by setting the latch on the domain object to open. The trigger function's forLatchOpen filter will only allow publishing an event when the latch is open, because the open latch indicates that the change originated in service one. The listener function's forSourceNotSelf filter in service one ignores the event because the source tag indicates that the event originates from service one. The listener function in service two closes the latch before saving the data by setting the latch on the domain object to closed. The trigger function in service two does not publish an event, because the closed latch indicates that the change did not originate in service two.

This same flow unfolds when the command originates in service two. You can add a third and fourth service and more, and all the services will remain in sync.