How SymmetricDS successfully replaced our complicated client-server architecture

With SymmetricDS , we avoided investing effort in designing, implementing and testing a complex, asynchronous communication protocol over web-service layer. Instead, we achieved a simple, intuitive interface that allowed us to deliver out solution within few days.

Our application started with a local standalone server that processes long running transactions. It naturally evolved to a distributed architecture. While benefits of the new architecture were clear to us and our customers, an issue arose : we would force our customers to enable their applications with boring and non intuitive web-services to communicate with our transaction server.

In short, the following requirements were considered:

  • The customer application creates data to be queued to our transaction server. Those data must be somehow uploaded to their respective transaction server instance that is running the queue.
  • Furthermore, if the customer updates data that was already sent to the server instance, then these changes must be reflected on the server, too (for shortness, I will omit details, but the transaction server handles transactions with input data that changes over time).
  • Finally, as soon as the transaction server instance concludes the transaction, the resulting status must be returned to the costumer application.

Since the transactions are long running, the requirements would probably resort to a complex, asynchronous communication protocol over web-service layer.

Motivated by the SymmetricDS features, we decided to adopt conventional database tables as communication a interface for our transaction server. The customer application is expected to insert and update data that shall be processed by the transaction server. The same table records the transaction status as soon as the transaction is complete. The transaction server contains identical tables as a queue of pending and completed tasks. SymmetricDS  does all the work of running the required web-services between customer and the transaction server to keep the tables consistent and synchronized.

I confess that such solution is really less fascinating than popular web-service/rest architectures. But the solutions was immediately understood by junior software analysts and inexperienced programmers. And allowed us to deliver the solution about 10 times faster than expected.