In addition to using postgres for data storage and retrieval needs, we used it to direct and coordinate a set of disparate workers. These workers represent collection of different programs that are parts of problem solution, operating cooperatively on the same large data set that is stored in the database. These programs are executed on different computer systems and rely on the DB to signal the direction and current state of progress. This approach allowed us to quickly adapt the system to changing requirements without the need to transform the programs and more importantly apply these changes with virtually no down time. Instead of the traditional approach where database plays a side-role in the blackboard architecture pattern, in our solution postgres is the key component. It provides a communication channel through notification events as well as a means to coordinate work. Each work component goes through the process of selecting an available worker, requesting its attention, instructing it to execute a part of work, and ultimately writing back the part of the solution, or the solution itself. This approach in combination with postgres as its engine allowed us to build up and scale our solution to a parallel system running in redundant modes with a self-correcting scheduler.

IPC techniques used will include communicating through data--leveraging Postgres atomicity features--as well through the LISTEN/NOTIFY mechanism.