Microsoft® SQL Server™ version 7.0 supports only a hub-and-spoke topology. In a hub-and-spoke topology, data flows among Subscribers through a single Publisher or Distributor. Direct communication does not exist between Subscribers. The loss of a single Subscriber does not prevent other Subscribers from obtaining updates, but the loss of the Publisher or Distributor disables the hub-and-spoke completely.
The hub-and-spoke topology reduces data latency time among all subscriptions to the publication because data has to travel three steps at most to synchronize with any other subscription. If the average quantity of data to exchange during synchronization is relatively small, the hub-and-spoke topology can be a fast and efficient solution. Potentially, the publication can be partitioned so that the amount of data stored at any one Subscriber is reduced.
There are, however, several potential issues for the hub-and-spoke topology. First, the first satellite to be synchronized does not receive any new data from the other satellites and the last satellite receives all the new data from all the other satellites. To make sure all satellites are properly synchronized, you must make two passes around the hub.
A second issue is that the hub is involved with every synchronization, and must therefore be able to handle a greater load than any of the satellites. As a result, the hub-and-spoke topology has a practical limit to the number of satellites it can support. An effective way of handling this is to create additional hubs with spokes and connect their hubs. An alternative is to place the hub on a dedicated high-end computer capable of handling a heavy load. However, if your application exchanges only a small amount of data with each synchronization, the hub may be able to support a relatively large number of workstations.
A third issue of the hub-and-spoke topology is that it contains a single point of failure: the hub. If the hub controlling synchronization fails, synchronization cannot continue among any of the satellites. This problem can be handled in code by assigning one of the satellites to step in as a new hub if the old hub fails.
The hub-and-spoke topology is a good starting point for many applications and can accommodate a variety of replication scenarios: