Bidirectional replication enables data to flow from a producer instance to a consumer instance and accept data from a consumer instance to flow back to the producer instance.

By default, replicated data flows from a producer instance to a consumer instance. Bidirectional replication reverses that flow. For example, a company might outsource its networking issues. The third party receives the networking incident records from the consumer instance, fixes the networking issues, updates the records, and returns them to the consumer instance. Bidirectional replication then updates the incident records on the producer instance. Bidirectional replication only works for records that originated on the producer instance.

To make data flow bi-directionally on the consumer instance, the system creates a producer instance on the consumer instance and a consumer instance on the producer instance.

If you look at the replication sets on the original producer instance, you see the replication set name and the automatically generated consumer instance. It has the same name appended with the suffix, -<long-number>-reverse, where <long-number> is a randomly generated number. For example, if Test is the producer replication set name, Test-2034802-reverse might be the name of the consumer replication set that automatically generates on the same instance. On the original consumer instance, you see the same names. Replication sets with the reverse suffix are read-only.

You can verify a consumer on a producer instance and a producer on a consumer instance by running https://<producer-instance-name>/xmlstats.do?include-idr and https://<consumer-instance-name>/xmlstats.do?include=dir on the producer and consumer instances. In the following image, the original producer instance is on the left and the original consumer instance is on the right.

If you must understand the implications of bi-direction and data transfer between instances, please see data privacy in IDR for more information.