The Broker 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. Welcome back to our season where we're looking at software architecture patterns and anti-patterns. We're starting out with the patterns. This episode, we're going to look at the broker pattern. Now the broker pattern was a big hot pattern to use back a few years ago. And by a few years, I mean now decades in the probably about the early mid maybe to late nineties brokers were like huge and they are still out there because it is a pattern that just makes sense. A pattern that is scalable, maintainable and is sort of how we do stuff anyways. It's a very, it's a natural type of pattern. And the way the broker pattern works is that you have a client as you always have client makes a request and they request to the broker. And then the broker looks at these servers that have been registered, these services that it knows are available and either passes that request out to the server that does that will perform that service or we'll say, sorry, can't do that. Think about this in the natural world. What's out there is somebody comes to you and says, Hey, I need you to balance my checkbook. Now you may look around and in this case, the server and the broker may be the same thing, but maybe you're not that kind of a person. So maybe you're more of a concierge. And so you look around and you say, okay, are there people that, is there a person I know that balances a checkbook? If so, I'm going to pass the client request onto them and say, Hey, here's the checkbook, balance it. You get it back when it's done, you give it back to the client and they're done. If you don't find anybody, you can say, sorry, I don't know me that can balance a checkbook. And so just like a concierge in a hotel, there's going to be certain services and things that are available. You're going to have the same thing with a broker. You're going to have servers that are able to do certain service, provide certain services, do certain calculations or other things. The power in this pattern is think about it. Think about this concierge that has, let's say a couple of people, two people working with them and one person can do laundry. Another person can take luggage to a room. So you have those two services initially that can be supported. But now let's say you add somebody else that is an entertainment specialist that can go get tickets to shows. Now you have new services. Let's say there's somebody that is a tailor. So now you have somebody that can do tailoring services. They can go fix clothes and things like that. Brokers are the same way. that they can have servers that are there initially and there are new servers that are added. But also in the broker world, you may have servers go down. It's no maybe, it may be that those services are not available temporarily. Normally you would go to server ABC for your accounting related services, but that thing's down right now. So you'd say, Hey, sorry, service not available. This is why this pattern became so popular when it was, I guess, I'll say first discovered is probably the wrong way to put it, but first really put to use is you have this idea of services which have been around for a while, but you have these services are out there and you have sort of a gatekeeper, a broker, a concierge. You have a front door that requests will come through. And so now you're not overloading the services themselves. Plus you have a way much like a phone operator to route those requests as needed to the places where the services can be provided. And if those services don't exist, okay, you're going to say, Hey, I can't find that service. But maybe you try today and tomorrow there's a new service available. And now that service that you know, you couldn't get that request today, but tomorrow you go through and the request goes through and you get your response. You get that work done. So you have a way to very flexibly expand the feature set. You may start with think like an ATM. You have an ATM that you start off with this broker, an ATM broker. And by ATM, I mean like a cash machine. You have this broker that initially allows deposits and withdrawals. And then later you come in and you implement a check on balance. And so now you have that service. And then later you have a balance transfer service. You can add those in. All of those need to be done without touching the broker and with really without touching any other servers. Because technically what's going to happen in the broker pattern is that a server comes up and it's going to register with the broker and it's going to say, here's the services I provide. And if you have multiple servers that provide the same service, the broker can actually start checking them. So you have a fallback that you may do some sort of load balancing or something like that. But you can also have a sort of a secondary kind of approach where go to the first server that registered and said, Hey, I can provide service a while somebody comes in and requests it. You know, sends it off to server, you know, to the server and says, okay, or tells the server, Hey, I have a request for you. I'm going to send it. Well, the server doesn't respond. Then you just go on to the next server that provides service a. So you have all sorts of duplicate duplications of work or coverage. So that if it's in, particularly if you've got multiple servers and multiple services, you can have those services live on two or three different servers. So any one server is not going to be overloaded, but it is going to provide a large number of services and can be backup or primary for those services through the throughout the system. And at any given time you can have a new server comes up, registers and says, Hey, here's some new services I have for you. The broker says, great, I'm going to add those to my list. If somebody requests it, I'm going to talk to you. May seem super simple, but in a sense it is. It's really not that complicated because it's basically server comes up, says, here's my services. Here's the signature basically for those services or here's what the request should look like. And so you're just going to have as a broker, you're going to have this list of requests. You have one comes in and it just keeps matching. And it says, boom, this request that I just got matches this one that this server says it provides. And so I'm going to make sure that server is still there. It provides it and send it along. And then when it's done, I'm going to send the information back to the client. So it's probably a request and a response, which basically just says, you're going to get a response like this, send it on. Or you may, because it's not a, it's not aimed at being load balancing, although there are some things that can do like that. It's really aimed at being a system that can grow without coming down. The broker never has to be rebooted so that the new services can come up. Service comes up, it registers with the broker. You're off and running. You can version stuff as well. So you can have version one of your service and then later add version two. And depending on who the clients are, somebody still only want version one. Some may now want to take advantage of version two. It's much like APIs and other things where that you want to support prior customers, but you also want to add new features or some upgrade for customers as well so that they can, you know, they have an upgrade path. And this is particularly if they're coding against this broker with these services. That way they don't have to rewrite their code when you create a new version. Instead, they can keep, keep hitting that old version. And then when they get around to it, they can write their code, update whatever needs to be updated and point to the new and improved version. The challenge with this pattern, of course, is those ideas that you have in your head where you're thinking, great, I can do this broker and I can start just like slapping in features left and right. I have a great way to build out a system, do it stepwise, do demos along the way of all these new services and just grow it as naturally as possible with given the resources and time constraints and things like that. Sort of like when you maybe have built an application where you've got, I don't know, say 20 different menu or navigation options or buttons. And initially they're all under construction, but you know, you can start coding behind them and eventually you have code that works. So what the broker is, you can say you can make all kinds of requests. It's just going to ignore most of them initially, but then I'm going to start building out ways to support those. And depending on the request style, what kind of requests the broker actually handles, it may be that you can look at requests that were turned away and say, oh, these are requests that I want to support. If it's some sort of like a natural language request engine, I think like bots and things of that nature, then you're going to look and see, hey, I get this request a lot that I don't support now, but I'm going to have to find a service. I want to create a service to do that. The customer has asked for it enough. I want to provide that. But doing so, you can end up with, as we've seen with some other things like the pipe filter, there are situations where it's just seen as such an easy way to expand that every little thing starts getting added in. And the next thing you know, you have this huge backlog. You got all these features that you want to add. You got all these things you're going to do. And the broker ends up essentially getting bogged down because it's supporting just way more services than it needs to. And there may be a granularity as well, because there may be some of those services that really should not be a separate service. But because we didn't think about it, it got built piecemeal. And instead, what we should do is have a service that actually provides, really combines or rolls up those three or four services or maybe more than that. So you still need to be really intentional in design for the broker architecture that you can. It's built so you can extend it. But you want to make sure that you build it first to do what you need it to do. An extension is a nice to have or something that will happen to allow you to roll with changes if there are some changes. But it should also be it should not be common. It should be something that is more the is more not the norm. That is is a outside of the norm that we're going to expand that out that way. Something that we haven't already considered in design for, because like everything else, if you start sort of duct taping stuff on and things like that, tacking stuff on, it ends up falling apart because it just it wasn't built right. Instead, you're better off building it initially for all of those features. And with the broker, this is great where you may have the idea of all those services and what they should look like. They may not exist when you first go to production, when you first make that broker available. But then you'll be able to come on later and say, now I have a server that supports this. So now I'm going to do something with it and I'm going to provide this to my clients. So we once again bump up against this, this idea that this architecture is cool. It's great. There's a lot of neat things we can do with it. It's it solves a lot of our we'll call growth kinds of problems. And in particular, in the world of agile and sprints, the idea that you can just keep tacking on features, you can do it in X number of sprints and then it appears as part of the broker. It's all awesome. It's just the APIs work the same way. Service oriented architectures are very much a broker kind of system. And there is a lot of power in them. But to quote Spider-Man movies, with great power comes great responsibility. So let's make sure that we still actually design these things, that we don't get ahead of ourselves and say, yep, we can do that without actually walking through. How should that work? How should that fit within the system? And how do we avoid that becoming something that we that we regret later on? So that is a broker architecture. Nice, simple, straight to the point. And that will wrap this one up, but we're going to come back. Don't worry. Not done yet. We have got more patterns than any patterns to look at. But until next time, as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor 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, the Develop-a-Noor 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 developer.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.