System Design - The Basic Building Blocks of any System
Choosing the right mix of these building blocks to meet those goals without over engineering the solution.
In our last post we learned how to gather requirements. We now have our blueprint. We know what the client wants the house to do (functional requirements) and we know the rules we must follow like budget, size, and location (non functional requirements and constraints).
Now comes the fun part. We get to pick our materials.
You cannot build a house without understanding what concrete, wood, glass, and electrical wire are used for. System design is the exact same. You must first understand the core “materials” or “building blocks” that every modern software system is made from.
We can split these blocks into two essential categories Core Blocks which every system must have to simply function and Advanced Blocks which you use to handle massive traffic, background tasks, and complex scaling requirements.
The Core Building Blocks
These are the fundamental components required for any application that serves users over the internet. You cannot build a modern system without these four blocks.
The Client Server Model (Foundation)
Almost every application you use from a website to a mobile app runs on a very simple model called the Client Server Model. This is the fundamental relationship that powers the internet.
It is a simple request and response pattern.
The Client
This is the device you hold in your hand or use on your desk like your web browser or a mobile app. Its job is to ask for things. It is the customer.
The Server
This is a powerful computer (or group of computers) sitting in a data center somewhere. Its job is to listen for requests, do the work, and provide a response. It is the shop.
Think of a restaurant. You the customer are the Client. The waiter who takes your order and brings you food is the Server.
When you (the client) want a meal, you make a request to the waiter (the server). The waiter goes to the kitchen (the backend), gets the meal (the data), and brings it back to you (the response).
This simple back and forth is the heartbeat of all system design.
How System Talk APIs (The Menu)
In our restaurant, you (the client) cannot just walk into the kitchen and start yelling for food or order anything they want. You need a formal way to communicate with the waiter (the server) and also what the restaurant can cook. You need a menu.
An API or Application Programming Interface is the menu for a software system.
It is a contract that defines exactly what and how a client can request information from a server. It lists all the possible orders (”GetUserProfile”, “PostNewTweet”) and what you will get back in return.
The client does not need to know how the kitchen (server) makes the steak. They only need to know how to order it from the menu (API).
The Core Operations in APIs (CRUD)
Most APIs are built around four basic actions you can take with data. This is known as CRUD.
Create (HTTP verb POST)
This adds new data. Example posting a new photo on Instagram.
Read (HTTP verb GET)
This retrieves data. Example viewing your friend’s profile. This is the most common operation.
Update (HTTP verb PUT or PATCH)
This changes existing data. Example editing the text in your post.
Delete (HTTP verb DELETE)
This removes data. Example deleting that same post.
REST or Representational State Transfer is simply a very popular style for designing these menus. It uses the standard web language (HTTP) and these CRUD verbs to create APIs that are simple and easy for everyone to understand. We will cover this in detail in a future post.
The Database for Storage
A server cannot just hold all its information in its head (its memory). It needs a permanent, organized, and safe place to store data. This is the database.
A database is the system’s long term brain. It is responsible for storing, organizing, protecting, and retrieving data efficiently.
A database is not just a pile of books on the floor (that is a file system). A database is the entire library. It has a librarian (database manager), a card catalog (an index for fast lookups), and organized shelves (data tables) so you can find exactly the book you need quickly and reliably.
In a future post we will explore the two main types of databases SQL and NoSQL. For now just know that the database is where all your permanent data lives from user profiles to blog posts.
The Cache for Quick Access
The database is great for storing everything, but it can be slow. If you have to run to the database every time you need a single fact, you will waste a lot of time.
This is where a cache comes in. A cache is a small, extremely fast, temporary storage area.
Think of a busy coffee shop. The main supply of coffee beans (the data) is in a big storeroom in the back (the database). It would be very slow if the barista had to run to the storeroom for every single cup of coffee.
Instead, they keep a small bag of beans right on the counter (the cache). This counter storage is much smaller but 100 times faster to access.
This is a cache first pattern. The system’s logic is
A request comes in for a piece of data (e.g. a user’s profile).
First, the server looks in the cache (the counter).
If the data is there (a “cache hit”), it grabs it instantly and sends the response. This is very fast.
If the data is not there (a “cache miss”), the server makes the slow trip to the database (the storeroom), gets the data, puts a copy in the cache for next time, and then sends the response.
Caches are one of the most important tools for making a system feel fast.
Advanced Building Blocks
Once your system moves past a few thousand users, the core blocks alone cannot handle the load. You need advanced tools to distribute traffic, decouple slow processes, and handle static assets. These blocks are required for high availability and massive horizontal scaling.
The Load Balancer (The Front Door)
In our first post we learned that horizontal scaling (adding more servers) is the key to handling huge traffic.
This creates a new problem. If you have 10 identical web servers ready to answer requests, how does the user’s request know which of the 10 servers to talk to?
You need a front door. This is the Load Balancer.
A Load Balancer is a special server that acts as the single “traffic cop” for your entire system. All requests go to the load balancer first. The load balancer’s only job is to look at all your web servers and forward the request to the one that is least busy.
Imagine a concert venue with 10 identical entrance gates (your servers) and a huge line of people (traffic). A load balancer is the security guard at the front. Instead of letting people pile up at Gate 1, the guard points to each person and sends them to the shortest line. “You go to Gate 5.” “You go to Gate 7.” “You go to Gate 2.”
This has two huge benefits
Scalability
It spreads the work evenly so no single server gets overwhelmed.
Availability
If Gate 3 suddenly closes (a server crashes), the guard simply stops sending people there. The system stays online without users even noticing.
The Message Queue
Some tasks are very slow. Imagine you upload a 10 minute video to a platform. The platform needs to process that video. It has to create a small, medium, and large version for different devices. This can take several minutes.
The user does not want to stare at a loading screen for 10 minutes. They want an instant response.
This is the problem that a Message Queue (or Messaging System) solves.
A queue decouples the fast request from the slow work.
Think of an old one hour photo shop. You (the user) drop off your film (the request). The clerk gives you a receipt immediately (”We have your film. Come back in one hour”). This response is fast.
You can now leave and go shopping. Your film (the task) is placed in a bin (the message queue). In the back, a processing machine (a worker server) pulls one roll of film from the bin at a time, develops it, and puts it in the “ready” pile.
When you come back, your photos are ready. This is called asynchronous processing. The user gets a fast initial response, and the heavy work happens in the background. This is essential for any system that processes videos, sends emails, or does any complex calculations.
The Reverse Proxy
A Reverse Proxy is a component that sounds similar to a load balancer but serves a different main purpose. It is like a security desk or receptionist for your system.
It sits in front of all your other servers and can do many smart things
Security
It can act as a firewall, blocking known bad requests or attackers before they ever reach your application.
SSL Termination
It can handle all the secure “https” parts of a request, so your application servers do not have to.
Caching
It can cache common files like images or logos.
Request Routing
It can direct traffic to different parts of your system based on the URL.
Often, a single tool (like Nginx) will act as both a load balancer and a reverse proxy.
The Content Delivery Network (CDN)
A Content Delivery Network or CDN is a worldwide network of servers that specifically stores your system’s static files. Static files are things that rarely or never change like your website’s images, CSS files, JavaScript code, and videos.
Why use it It is about physical distance. If your main servers are in New York but a user is in Tokyo, their request has to travel halfway around the world. A CDN places a copy of those static files on a server in or near Tokyo. This drastically reduces the distance the data has to travel leading to a much faster website load time for that user.
CDNs are a fundamental part of designing for global low latency and an absolute must for high traffic sites.
The Next Step
We now have two clear categories of tools.
The Core
The Client Server Model the API the Database and the Cache are the absolute minimum to get a product working and performing well.
The Advanced Layer
The Load Balancer the Message Queue the Reverse Proxy and the CDN are the tools you add when you are ready to scale globally, handle massive concurrent users, and introduce complex background processing.
Your job as a system designer is to identify your requirements and then choose the right mix of these building blocks to meet those goals without over engineering the solution. Start with the core and introduce the advanced blocks only when your non functional requirements demand them.
Now that we know our blocks, it is time to look at the different ways to put them together.
In the next post, “From Monolith to Scalable Architectures,” we will explore the patterns of design. We will start with the simplest (and most common) pattern the Monolith. We will see why it is a great starting point and at what point it starts to break, forcing us to evolve toward more scalable designs.