Now, this diagram is going to encapsulate a lot of what we've learned throughout the entire course because there are all kinds of different components that need to be integrated in order to have a system like this function properly.

Notice that we have multiple calls to the Internet. Whenever you see this in a deployment diagram it means that you're most likely interacting with some type of API or you're showing how the direct communication is going to happen with a user like we have right here. So starting here on the top left-hand side we have a user who's going to make a request. We clearly show that that request is going to come through the Internet and that may seem like a straight forward kind of thing to say. However, there are plenty of times where this might be, not a user but some other API or something like that.

And if you come down here that's actually what we have here and that's part of the reason why I have this little computer used as an icon and this is perfectly valid UML deployment diagrams are some of the most visual types of diagrams that are out there because there are many times where, as you can see these different nodes all look very similar. But whenever you look at the user you can tell that that is someone's computer with their desktops so that very quickly shows that this is going to be a user who's just working on their computer sending requests.

Now that's different than what we have here. This is an outside user it's an outside client that is going to be interacting with the system using the Internet. But this is going to be something like salesforce and this is an integration that we've built-in with the marketing automation system where we can communicate with salesforce and update different records in the salesforce database based off of how the journey is and how all of the different systems on the marketing automation side are happening now moving down after we have that. All of that communicates with a load balancer it doesn't go straight to the servers it has to communicate with the load balancer first and that is going to dictate how the traffic is going to flow. So the load balancer is going to split up the traffic. And in this case, we're still just using two application servers. However, this could be stretched. You could have this stretched over five or 10 servers if you have a massive application and the load balancer can manage all of those processes.

Now each one of these application servers is also going to communicate with a shared database. So right here we have a database cluster.

We have our DB master and then our DB slave. And so if you are familiar with how databases work especially in architectural level then you know that the DB master is what these application servers are actually interacting with and then the slave is your replication system so you can have your database backups and you can make sure that if your DB master goes down then it can be instantly replaced with this slave.

Now, this is a pretty standard setup for load balancers. Each one of these application servers is going to have the identical code. And because it's interacting with the same database right here then the user experience is always going to be the same. Now moving down these are going to use an e-mail server which is going to be a separate service I'll use services such as Sparke post or send grid and those kinds of tools. And those are not inside of the servers. They make API requests to that outside service. And then this email server is in charge of processing all of those e-mail requests. And that's a reason why I have use because we're using this service and then continuing down with that same pattern. The system also needs to communicate with an SMS gateway for the applications I work on that require SMS. I usually integrate Twilio, and Twilio is a great tool that allows you to send SMS messages via API calls. So our application servers are going to interact with the email system with the SMS gateway and if you also are going to extend this even further it can use all other kinds of systems so you could extend this to use slack, to be extended to use hip chat to all kinds of other outside services and they would just continue down the line.

Now the last component here is this SMS gateway is going to use the Internet so it's making an API call and then that's going to be what is going to communicate with this provider. Now the way that we have it set up we don't have the application servers directly interacting with Twilio.

Instead we built a wrapper for that so that each one of the servers can send custom messages and it doesn't have to worry about the Twilio API at all. It simply sends it to this SMS Gateway and then it handles all of the processing. It's an application that stands by itself and it handles 100 percent of the processing for communicating with Twilio. And the really nice thing about this is if you're building out a system and say that you did integrate your Twilio or any API connectors right inside of the app server code if one of those providers say Twilio decides to change the way that you need to communicate with the application with their system then you'd have to go and change your core code you'd have to alter the code base just to make it change to fit in with Twilio's changes.

And that's really considered a poor practice. You don't want your system to go down just because Twilio decided to make a few changes. So from an architecture perspective what I like to do is I like to create some type of gateway a type of wrapper that I can have 100 percent control over the system. I can take better care of having custom error messages if Twilio does change or if there's a outage on their side and then I can communicate that much more clearly to the servers and to the code base as opposed to relying on them to do it. So I'll usually create some type of wrapper many times like in this case it is a standalone API only application and then these apps simply communicate with it.

It manages all of the connections between Twilio and then Twilio will send back all of the data when you get a response. And then obviously it is in charge of sending those SMS messages directly. So that is a marketing automation systems deployment diagram that includes everything from outside API calls to tools like Twilio and salesforce and also how you can configure a load balancer.