Backend design

When I was younger – as in less-than-a-decade old – I wanted to be an architect. That was, until I learned about the existence of trigonometry, calculus, and all the higher-than-geometry level math I could never possibly hope to understand. I liked drawing houses and castles, not mathematically planning them.

Many professions, just like that of architect, necessitate the mastery of hidden skillsets or knowledge bases that the layperson isn’t aware of; the perfect example of this being backend developers. The title, and the topic that comes with it, is enough to make most people instantly glaze over – even some frontend developers will look for an excuse to escape from the conversation.

There’s a reason that this blog is titled “backend design,” however – a lot more design goes into backend development than you would think. Or, more accurately stated, a lot of design goes into architecting the backend.

Systems architecture

According to Introduction to Systems Architecture Design by Medium, backend architecture is “… a conceptual representation of the components and subcomponents that reflects the behavior of the system.”

In other words, backend design is architecting a structure for the frontend, user-facing data layer. It’s akin to designing a car – there’s just as much artistry necessary as engineering. Code is code is code – there’s nothing special about Ruby on Rails or Node.js. Once mastered, the language of the backend can be written just as fast as a frontend developer working in Swift or JavaScript.

Just as a good UI designer knows how to create a rectangle in Sketch, so to does a backend developer know how to build a NoSQL database: the true skill of design is knowing where to place that rectangle in order to create a pleasing layout, or how to organize data in order to minimize latency.

So know that when someone starts talking about systems architecture, they’re really talking about architecture, and less about code. And once this topic is broken down, it’s not that complicated (on a high-level, at least) to comprehend.

The backend can be broken down into three layers:

1. Controllers – these handle client requests, such as when a user adds an item to their cart.
2. Services – access data in the DAO layer, and send it back to the controller, which then sends the retrieved information to the client.
3. Data Access Objects (DAO) – This is the layer where data can be stored, organized, and accessed.

Most often, these layers can be implemented by cloud providers; these platforms – like Amazon Web Services, Google Cloud Platform, or Microsoft Azure – will sell managed services like on-demand servers, or databases (in addition to many other services).

When someone speaks to the scalability of the cloud, this is what they’re referring to; “the cloud” is really a collection of remote servers that provide customers with ready-made backend infrastructure, giving companies the ability to increase their operations without needing to store, manage, and maintain servers physically on site.

Within these layers are components, of which we’ll cover the four most basic and widely-used:

1. Virtual machines – Like most things in the world of computers, the moniker “virtual machine” is an apt descriptor of what VMs do; a VM is nothing but a computer simulated inside of a computer, much like a digital Russian nesting doll. When utilizing cloud providers, VMs will be hosted on larger servers that allocate the necessary CPU, RAM, SSD, and network bandwidth in order to run your VM – this exact process can be achieved on a personal computer as well. VMs run the operations of your backend.
2. Load balancers – Run too many applications on your computer, and it’ll start to slow down. The same is true for your VMs in the cloud or on your local servers – too many client requests, and the time it takes to load a page can skyrocket. Your backend’s load balancer is designed to solve this problem: load balancers act as a medium between your backend’s controllers and services layer. Load balancers both interpret client requests from the controllers layer, and keep track of the health of VMs – and to ensure low latency client request, the load balancer distributes those client requests evenly between VMs.
3. Databases – Databases are how your DAO layer is organized. There are two types of database structures: non relational (NoSQL), or relational (SQL). We’ll cover those a little bit below.
4. Caches – The reason databases can have different structures is because certain databases are optimized for different types of data, in order to decrease the time it takes to access information. Caches are used for the same reason; during times of heavy traffic, caches can store data that is sure to be accessed in rapid succession by many clients, thus reducing the time it takes to complete client requests. Caches can be thought of as super-optimized, small databases.

Back it up

Before we get into anything more complicated, theres a few basic concepts we can go over now that we’ve covered the building blocks of the backend:

1. Latency – This is the length of time it takes a client request to complete. Latency always refers to time.
2. Bandwidth – This is the maximum amount of client requests (data) your server can handle.
3. Throughput – This is the true amount of data your servers can handle. Often, during times of high traffic, bandwidth will drop as latency rises – this new measurement is called throughput.

In order to reduce latency and increase bandwidth, backend systems will be scaled up to process more client requests. This can be achieved via three different methods:

1. Vertical scaling – This method reduces latency by increasing the amount of requests a single VM or physical server can handle by upgrading the CPU, RAM, or SSD of the machine.
2. Horizontal scaling – Reduces latency by adding more VMs or physical servers, thereby increasing the number of client requests that can be handled at a given moment.
3. Auto scaling – uses the same principle as horizontal scaling, but automates the process: VMs are added as they are needed, and deleted as client requests decrease. Both auto and horizontal scaling necessitate a load balancer.

Another design choice that can reduce latency is the type of database your DAO layer makes use of. As stated above, there are two types of database structures: SQL and NoSQL. While SQL databases are organized to write data in a very efficient manner; NoSQL databases are organized to read data quickly, but due to their structure, require duplicate data in order to access information.

You can think of a SQL database as a collection of tables that hold very specific, uniform sets of information, that link up in a web. NoSQL databases are structured in branches, which lead to other branches, which lead to other branches.

Both come with their pros and cons – NoSQL databases can access information faster, and are optimized for dealing with un-related sets of data. SQL databases are robust and optimized for dealing with requests that require relational data from various processes in your backend’s service layer.

Back in business

Just as a house would fall apart without the wooden structure, plumbing, wiring, and ventilation, so to would your website or application without its backend. It’s important to know what’s going on back there!

Stay tuned for our future look into scaling up your backend systems.