We’ve gotten this far, congratulations. It’s time for us to talk about network level architectures, or how different groups of software communicate with each other.
Whenever we are talking about communication, there is always a phrase that comes up in software that defines the nature of how code talks to other code. This concept is the concept of a protocol.
What is a protocol
Protocols are widely used in both software and non-software communication across the globe. A protocol is essentially a set of rules that the two parties agree in when they are attempting to communicate with each other. When you are reading this article we are using a protocol that is called the English language. This protocol consists of various subsets, like the alphabet, the syntactic ordering of letters, the semantic meaning of the words and the grammar that is behind the entire thing. All of these things are required for you to understand the words that I am typing tight now.
The same is true for software. In order for 2 systems to talk to each other, a protocol needs to be established. Probably the most famous protocol that you might have heard about as well is the HTTP/HTTPS protocol (yes, this is the one you can see in your browser and all the meme links that you send to your friends on Instagram). We are not going to talk about this a lot now. What’s important is that we are going to draw some diagrams below where we will be using lines. Lines indicate communication that require a protocol. On the lines we usually indicate what protocol we are using, in all the diagrams we are going to assume that we use HTTP/HTTPS protocols.
Clients and servers
Now that we know what a protocol is, we are going to talk about other atomic building blocks of network level architectures:
- Client - A client is a system that would like to access information from another system.
- Server - A server is a system where we store some information or do some specialized computation that clients do not have access to. Servers can also act as clients, if they require information from other servers to complete their work.
A client can be you, browsing Medium in search for an interesting article. In this case we can draw a diagram that looks like this figure:
In the above figure you can see a client making a request to a server. In this case the request is happening over the HTTP protocol to medium.com. The Medium servers process this request and return with a response that is the page rendered on the medium.com page. Making requests should be easy and in this case is most likely done using the browser of the client (i.e. typing medium.com in the url bar of the browser that the client is using).
Behind the scenes there might be things happening, of course. When we make the request to the medium website for an article, there are systems which are fetching additional data for the given page that we would like to examine. I am not familiar with the medium infrastructure, but it might be easy to imagine that when we are requesting an article, we would also like to get the comments with it. If I were Medium I would store the comments on a separate system, in which case the communication might look something like this in the background:
In the above figure you can see that we are fetching information from the comments server of Medium from another server and returning the comments. This can be useful if you are trying to separate some systems from each other. Some teams might specialize in rendering the articles in Medium, however, they might be not very good at maintaining comments, so another team will take care of that for them. This is something that we call domain-driven design in software, which we are going to take a closer look at in a later article.
Oftentimes servers themselves don’t host data, they just collect it from various places and return it to a client. These places are usually some sort of cold storage (remember from the architectures above?) that are accessed using different (usually faster but more difficult to understand) protocols. This was just a very difficult and long way of explaining databases. Thanks, Akos.
As you can see on the above diagram, the comments server has made a select request to the comments database and then that database has returned with a list of comments to the server that it can later return to whoever needs it. The main idea is that the comments server owns the domain of comments, meaning it knows the rules of how commenting works, like who can comment on what articles, profanity filters and even logic of how comments relate to each other, whereas the database hosts only the data of the comments and does not worry about the business logic behind them.