The Master Slave Pattern

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season. We're looking at software architecture, patterns and antipatterns. We're in the pattern phase of the season still, and we are going to talk about the master slave pattern for this episode. Now master slave has connotations that people may not like the whole slavery in general and having a slave, but this is about systems. It's not about people. And it is one that is a little different from what we have discussed so far because the earlier patterns we talked about really were more about an overall system. The master slave pattern actually is more about solving a problem, about doing work that needs to be done and distributing or delegating that work across multiple resources. For the client server pattern, what we saw was the clients basically would get requests and they would pass stuff to the server and the server would do some of the work, depending on how we delegated that. Sometimes the clients did a little bit, sometimes server did it, but essentially the server was a hub and spoke method way to basically connect everybody. Is that you had all of these different clients and they could have some sort of shared interaction through the server. Master slave is different because the slaves really don't communicate through the master. Instead what happens is a master server or service gets a request and then it pushes that work out to the slaves. This is a little different, whereas the workload really is shared in a client server system and is more about a community with a central place to communicate. Master slave is almost the inverse. It is a single point of interaction, the master, and then the work is pushed out to the slave. You have almost an abstraction layer of the work for the slaves to that master service. You sometimes see this in, for example, which we'll talk about another time, is the model view controller type of approach. where you have the view and behind it you have the controller and the model. You have this other stuff that's going behind it. The work is done not necessarily on, for example, the web server. Instead it's done in the backend and then it's presented up to the front end and that's shown to whoever the user is. In this case, a request is made to the primary, the master server or service or application. That then splits up the work or splits up the request into smaller chunks of work that are sent out to the slave servers or slave machines or processes. It's important to note that there is not, with the slave things, those processes and servers are not the same necessarily. It could be that they have different strengths. Maybe you have some of them are better at general data processing. Some maybe do data manipulation. There may be some other things out. Some of them may be persistence related. They may have different strengths and different weaknesses, but also they don't communicate amongst each other. They all run everything back up to that master process, which its job is to not only split up the work for that big initial request, but also to essentially take the results and put them together for a result for that request. It's not uncommon to see this kind of a pattern used all over the place. The master is sort of a manager in ways. For example, think of a development team. A development manager may get a request to build an application, to provide an application. What they do is they go out to the team members and say, hey, I need you to code this. I need you to test this. I need you to document this. They do all of that and then the manager puts it together. Or an editor, for example, for a book. Let's say that somebody's request is, I need a book that covers patterns, software architecture patterns. With the person, the primary requester, that master request person gets it and says, okay, I've got writers. I am going to send out to them and I'm going to break it into patterns. For each pattern, I'm going to send it to one of my researchers' writers and say, I need you to write, let's say, a chapter on this pattern, this software architecture pattern. They send it out to all of the writers. The writers do the work. Each of them, as they are done, ship that back to the editor in this case. Then the editor puts all of those together. Then, probably even in this case, which you may see in a master-slave pattern, maybe it does some additional work. In the editor example, they're probably going to write maybe some sort of a preliminary chapter. Maybe they write some sort of glue from chapter to chapter, some way to make them flow a little better. Of course, they're going to do things like outlines and things like that, maybe an overall appendix or references or things, bibliography, things like that. Maybe the individual ones, they may do on a small scale or just for their work. But then when that's brought together by the editor, the editor is going to put those pieces together to give you a finished product. We see this in all sorts of ways as well. I think if you look at an assembly line a lot of times, although that's not done in parallel necessarily. It's usually a little bit more serial. But same sort of thing. If you want to put together a car, then that probably goes out to various assembly lines to put together the body, the engine, the chassis, the wheels are done, all that kind of stuff. Then there is some sort of finishing process that brings all those things together. Well, sometimes that's if in this case, it's not quite that because the master is not the finishing process, it's the start and the end. Everything flows through that server or process. It does all of the splitting up of stuff. It does all of the merging and then it returns that result for that request. Now with this, it actually is a pattern that is useful. Almost anything that does require, I will say, we'll call it significant, although significant that is up to debate what is significant, but requires significant work. If you have something very simple, it's not going to make any sense. In math, for example, if you get a request to add two plus three, it doesn't really make sense and it doesn't. It would be very difficult to split that up. However, if it is to add every number from one to a hundred, OK, then you could split that up and split it into maybe let's say four pieces and numbers one to twenty five and twenty six to fifty, fifty one to seventy five, seventy six to a hundred. Get those results and then just add those four together. You'll see that in mathematics in particular, there are times where there are very complicated computations where it makes sense. It's easier to split that up. If you get into algebra and calculus, differential equations, a lot of times that's what it is. Let's break this big thing into smaller pieces. We see this in software. We'll see this in ways that we may find a way to slice and dice the request itself, particularly with sets and collections. So if I were to, for example, let's say I go to request to send an email to everybody in my email list, I can do that in one on my one server, one service. I can say, OK, I'm going to take this collection. I'm going to walk through it and I'm just going to crank out all these emails. But I could also say, all right, out of this collection, take the first twenty. If I know the number of them in there, take the first 20 percent, ship them off to this other server and then the next 20 to another and another and another. So that now instead of me, the master server or process doing the work, I'm now farming that out to these other servers. Bonus here is I may be essentially single threaded. And so instead of and you can think of this as a threaded type of approach, too, because now instead of me having to go, you know, item one, item two, item three, item four, I split this up and now I can do, you know, items one, twenty one, forty one, sixty one and eighty one all at the same time and then two, twenty two, forty two, sixty two, eighty two, all at the same time in large sets. I think you can see where you can now farm this thing out. And overall, you're going to get the work done a lot faster because you have more things working on it. Things, problems that can be broken down into work that is well suited to be done in parallel. Perfect for master slate. However, that's the key. If it breaks down in a way that you then have, you know, maybe there's some sort of waiting within that. So you have if you split it up into five different servers, but they each end up in these situations where they're waiting on each other because the work generally needs to be done in serial, I'm sorry, in serial, then it's going to be a challenge and it's going to be potentially not worthwhile because there is overhead. You have to that primary process has to split the work up and then it has to gather the results from all the places it farms it out to and put it together for a single to get that result back. Sometimes it's easier for just that one server or that one process to just do it itself. Some work is not meant to be split up and delegated. But don't let that deter you, because there's also some cases where it's big work, but it's different types of work. And so you have a server or process that is well suited for one type of work, but not for another. For example, you may have a program that is doing a lot of graphical manipulation and then it gets some requests. Part of its request is it has to do relational data work. You know, maybe it's got to do manipulation across large sets of data or something like that. It may make sense in this sense to break off that piece, that data manipulation piece, and then push that out to a database server or something that would be effectively a slave system where it says, OK, I'm giving you work. When you're done, I need the results back. So it's that single point is divvying up the work, getting the results back, merging everything and then sending that back to somebody. Like I said, that's very different from client server where in that case, the clients are getting requests. They may be sending and they're it's sort of a one to many versus many to one. And MasterSlave, you have one thing that gets the process and it has many back end pieces are doing the work. In client server, you have many the clients, many things are getting requests, and the server is the one that is basically dealing with all of the work for all of those requests. They're almost inverted patterns of each other. And they can exist within the same system, too. You may have a client server system that on the server, it may have a MasterSlave pattern that is used to handle some of that work. And that would be one that would make quite a bit of sense because you would have almost like a load balancer. And that's what a MasterSlave is, is if you do load balancing where your stuff's coming through one spot, you're balancing that out across different resources and then pushing everything back up through that one, that load balancer, that initial contact point. So that is the MasterSlave pattern. It's fairly easy to, I think, to comprehend. Implementing it can be a little challenging, again, because you have to remember, you have to understand how to break that thing up, that problem, that task or that job up into pieces that can then be put back together. And if you have multiple requests coming through the master process, you have to make sure that as you ship stuff out, you know which result goes to which original request. So there are definitely some gotchas that are in there. But generally speaking, it's not too difficult to, I think, to comprehend. And you probably can think of some ways, particularly with the examples provided, to make that a useful pattern for some of your larger jobs and tasks. That being said, I'll let you get back to it. Hope you continue to hang out here and walk through some of these software architecture patterns that we are going to go through. We're going to talk about any patterns later in the season and try to help all of us get to be a little better at architecting solutions. But as always, go out there and have yourself a great day, a great week, and we will talk to you. Thanks. Thank you for listening to Building Better Developers, the Develop-a-Nor podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success. One more thing before you go. Develop-a-Nor podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.