The reason is because every project that you come into and that you're asked to build is going to propose some unique challenges.

Starting with the load balancer, I went with one of the most basic options here,k which is a 50 percent traffic split. This means that if I get two requests then the first one I'm going to be sending to the first application server and then the second one I'm going to be sending to the secondary server. So if User A comes in when they go the Web site the load balancer takes that traffic and redirects them here. User B hits it right afterwards and then they are sent here and

The whole point of using a load balancer is pretty much like it sounds. You want to balance the load of traffic so that you're not so dependent on one system. The other nice benefit is if there's some kind of fault with this application server, and it goes down, then this other server can take all of the requests.

There are a lot of details that go into building a load balancer. This is a pretty straight forward implementation. You have to perform checks, such as a response from the application server to make sure it's running okay, and so on. Right here, I'm performing a pretty basic structure where we have a 50 percent load going to one and 50 percent going to the other.

So how are these application servers able to serve identical content and pages to the user? A lot of it comes down to the cache cluster. What caching allows you to do is to be able to save references and other components either on the user's system or on your own server. This is a critical component when it comes to improving the performance of applications. A lot of frameworks will do some of this work for you. For example the Ruby on Rails framework has caching built into the system for items such as CSS stylesheets and Javascript. For more advanced applications you usually have to perform some type of caching by yourself.

There are a number of services, such as Cloudflare or Amazon AWS that allow you to do this. I usually put my cache cluster on a third party service. I'll have them store my assets, my HTML, and the like, because those items are not going to change on a regular basis.

I also have the ability to make the cache expire. For example, I may push up a change to the server and then I may forcefully expire this cache so that it pulls in the new version of those files. This is especially useful if I made changes to the CSS styles or the Javascript. That's just a very high level overview of how caching works.

Lastly, we have our database cluster. Part of the reason why I structured it this way is because this is a pretty common pattern. You want to be able to cache certain items that are not changed on a regular basis--usually view-centric items--however, you don't want to cache data. Imagine a scenario where you have a user who wants to go check the status of their maintenance request. If you cache that maintenance request then that record is not going to update for them, even if someone went in and did change the status. So it's very important to understand which items should be cached and which ones shouldn't. Usually the way that I will run something like this is anything that changes on a regular basis I'll place inside of the database cluster and then I will not perform any caching on that.

I want to be clear that, just because I usually reference caching for HTML/CSS/JS assets, there still can be some level of caching that's related to data. On that side, you just have to make a decision on what data changes on a regular basis and what you want to give your users access to.

Great job going through that project. Hopefully now you have a better understanding of how load balancers work, how caching works, and how it can be applied in a deployment diagram.