Now you want to look at where the data changes will originate and where these changes need to be sent to allow users to access.
Part of this step is also to determine if the change flow is unidirectional or bidirectional. A unidirectional change flow means that between two sites, changes are only made at one site and sent to the other site. A bidirectional change flow means that changes can be made at either of the two sites and are sent to the other site.
Network pathing is also essential to your design. In many systems, there may not be a direct network connection between the source and target database. The network topology may require routing the Propagation through an intermediate database. This is known as a directed network environment. While the intermediate database may be used to route the change, you may or may not need or want to apply the change at that database. If the change is not applied but "passed" to another database; this is known as a "pass-through" transaction.
Again, understanding where changes are being made, sent, and applied will help you determine how much configuration work you will have ahead of you. You will identify any special handling rules that will need to be defined at each site. This step dictates which sites must be configured for capture, which sites to configure propagation, and which sites must be configured for apply. You also take it down a level by determining any special tagging and/or transformation and handling rules that need to be defined and coded for each of the capture/propagate/Apply processes and directed networks.