Controller Responder Pattern

Introduction to Controller Responder Pattern (Master/Slave)

The Controller-Responder paradigm, often known as the Master-Slave pattern, is frequently employed in multi-threaded applications when multiple instances of the same problem must be solved. (For instance, the "Traveling Salesman Problem"). To handle these instances "parallelly," the master produces and launches slaves. The results are harvested by the master after all of the slaves are done.

Servers and user interfaces both employ the master-slave pattern. In both situations, the master keeps an ear out for commands coming from either users or clients. A slave is launched to carry out a command once it is received, and the master begins waiting for new commands.

How Does It Work?

This pattern has two parts, the controller and the responders, just like the client-server architectural pattern. The controller component divides the input or labour among identical responder components and, from the outcomes produced by each responder, creates a composite result.

The master receives the requests. The master then divides the job into portions and assigns it to the slaves. The results of the task are delivered to the master by the slaves. The master then compiles the results and offers the final result for the request. The task at hand can involve calculation, requests from other parties, or the use of several persistence engines.

Example

Postgresql is employed as the master in the example diagram. Postgres is a relational database management system. Relational databases are organised and simple to maintain.  MongoDB, a non-relational database or a NoSQL, is chosen in this case for the slave. In Though slave databases do not have to be NoSQL, there is another case where MySQL is used as both master and slave. It can be convenient to utilise the same type of database for the master and slave because, in the end, maintaining the codebase will be much simpler. The replication procedure handles data transfer/synchronisation from the master to slave databases. You can use a serverless function, for instance, as a pipeline to distribute data to the slaves when replicating data. It is advisable to use a database replication tool because creating your own solution to replicate databases can be laborious. If you'd want to manage data in real time, you can also create an insert function that adds data to both the master and slave databases.

Advantages

• The capability of a request to be shared across resources is the strength of this pattern.
• This pattern has the important benefit of allowing analytical programmes to read data from the responder component without altering the data in the controller component.
• The responders can be turned off (taken offline) and then switched back on (taken online) without wasting any time.
• Master-slave is an alternative to caching for optimising I/O in your application. Writing only takes place in the master database because it is where the real data is stored. While reading is only done by the slave.

Disadvantages

• The data could be lost if a controller fails, and the programme might need to be restarted. A responder may be elevated to the controller in certain circumstances, but only with some data and technological deficiencies.
• The task is broken down further, and the outcomes are combined. Depending on the project, that alone may require a lot of resources. Therefore, we should apply this pattern only to huge projects with clear divisions.
• For many tasks, the master-slave structure is not appropriate. Splitting the effort into smaller parts will be difficult, or the request might be small enough not to require it.