Mark Solda

Project Management • Stakeholder Management • Project Planning • Product Lifecycle Management

​

One way to share databases to multiple geographically distinct location is to use database replication.  The alternative is to have remote locations connect to a single, central database.  These remote connections could be geographically very distant and need to pass through multiple networks, often leading to performance issues and for managing trading risk, the application my company provided, this can become a significant problem.

Shortly after the Database Team was created, I was approached by a client with a request on setting up a replication system so that they could take their centrally located database (in NYC) and have copies of it in four separate databases in diferent locations (such as London and Hong Kong), updated through two-way replication so that each location could update their local copy and have those updates distributed in real-time to the other database instances.  This would significantly improve performance for the locations outside of NYC.

The client gave me a fixed timeframe of three months for delivery, which would have given him enough time for testing before final proudction deployment.  If we could not meet this timeframe, the client said he would have to look elsewhere for a solution.  After informing management of the request, including the timeframe, and receiving approval to proceed on it, I worked directly with the client, elicting final project requirements.  One of the criteria was that it had to work with the version of our company's software they were currently using.

Working with the rest of the Database Team, modifications to the database schema to support two-way replication were worked out, scripts written to automate these changes and a testing cycle was begun.  At the end of successful testing, including integration testing by another team, the deliverables were ready to be shipped to the client, one week before the deadline.

Unfortunately, the client had taken our agreed upon delivery date, assumed a delay and expected delivery one month later. He was not able to accept the delivery because he was on vacation.

After the client deployed the deliverable to a "mirror" testing environment, all went smoothly.  Performance for the traders, regardless of location, had vastly improved, including the NYC server, whose load had vastly decreased.  However, a single trader noticing the increased performance in the testing environment entered his trades only in it, thus creating a significant data integrity issue, that the client had to resolve.

No issues were found with the deliverable, though one problem was incorrectly attributed to the it but was found to be an existing bug elsewhere.