Though there are a lot of server types in the world, how those servers are set up in your company/business/home/etc is equally important, and is often referred to as models of communication, or architecture.

As explained in our Server Basics post, servers can be big or they can be small. You could imagine that a little tiny server like this could not possibly handle the workload of servicing millions of internet users around the globe on Pinterest.com.

And that’s where architecture comes in. Your architecture has to be able to not only handle the workload for your company or business (like Amazon.com, Google.com, Pinterest.com, etc.), but it also has to be set up in a way that will support client requests.

There are several types of architecture models you should consider during your studies:

• Client-Server Model
• Peer-to-Peer Model
• Request-Response Model

Keep reading as I try to break down the different types of architecture models using Beyonce gifs.

CLIENT-SERVER MODEL

Let’s say you’re a huge Beyonce fan. You love her music, her concerts, and her Lemonade album is your life soundtrack.

What happened when Lemonade dropped, besides pandemonium? Well, you (the client) probably went to the internet to search for her visual album.

So let’s say you went to Google Chrome and searched for her album. Your Google search for her Lemonade album is called a request – you requested for Beyonce’s Lemonade album using your Google Chrome browser.

On the other side of that request is Google, which has a server that handles multiple requests from people across the globe, including those requests from Beyonce fans.

While you personally may want to see her Lemonade album online, her 50-bajillion other worldwide fans may want to request something else. Like what building did she bust out of with all of that water?

And the fan-favorite question, “Who is Becky with the good hair?”

Now physically, Google’s server is located somewhere in America, but you could probably care less. You want to see the Lemonade visual album right now!

To ensure you’re able to get your request fulfilled, a team of Google techs work day and night to ensure that you have access to everything Beyonce in the Google search results, and more.

Once Google receives your request, Lemonade pops up in your Google search results and lists YouTube as its location. You click YouTube and allow the Beyonce binge-watching to commence.

And that’s basically how the client-server model works – a client sends a request and yields a response from the server.

PEER-TO-PEER MODEL

In a peer-to-peer model, your device can be a server, my device can be a server, and anyone else’s device can be a server while simultaneously sharing information.

So let’s say you belong to a Beyonce fan club Facebook group. In that group, you meet another super fan named Sven, who claims to have some never-before-seen gifs from Beyonce’s Lemonade album.

Being the super fan that you are, you find yourself itching to see what Sven has for you.

Sven gives you a link to his BitTorrent and tells you to download the gif. The BitTorrent is the server.

You download the gif, only to find out that the gif he was referring to was not Beyonce.

In another example of Peer-to-Peer, let’s say that you send Sven a Beyonce gif through the BitTorrent link. Now you’re the server. See how simple that is?

REQUEST-RESPONSE MODEL

Let’s say that you find a new community of Beyonce fans on reddit. You go to Google, and type “reddit.com/Beyonce” in your browser.

Your browser sends you to “reddit.com/Beyhive”. That could be an issue.

After some investigating, you find that reddit shut down the old r/Beyonce community, and started a new one called r/Beyhive. In this case, your DNS server was doing it’s job, and redirecting you to the correct community. So yay!

And that’s how to Request-Response models work. According to code analogies,

I found the videos below helpfuli