2.1. The Case for Database Replication/Synchronization

Database Replication can offer many advantages to a distributed application, including faster database access and fewer downtimes, but only if it is done correctly.

In a POS application for instance, where all customer data and sales records will be replicated to all sites, you are essentially creating near-time backups of your data at all of your sites. If one location's data repository were to fail, it is relatively trivial to restore that location by retrieving another snapshot of the data from the publisher. In this particular scenario, database replication is being implemented to provide a high-availabilty solution. This is hardware-intensive, as each site must be capable of supporting essentially the entire database, but it allows for network interruptions. Thus the initial cost of entry is higher than with one centralized server and simple clients at the remote sites, but it doesn't require high-end connectivity options.

Another valid application of database replication would be pushing transactions up from mobile devices or laptops, and syncing customer records. In this case, only customer records are being synced back down to the subscriber, and thus the load on it is much less.

You do need to be careful when using database replication, however. Designing or modifying database tables to be replication-friendly is a very important, and choosing which data to replicate and how frequently to sync are very important descisions.