The aim through these system design pieces is to help the reader develop a solid grounding in applying concepts to real projects.
Things are usually a lot more complicated than they look. If you wanted to build a concrete wall, what comes to mind initially is the bricks and cement and so you may assume that it is a straight-forward done-within-a-week job. That’s until the mason calls you asking for the rebars, tar paper, wood, all of which you hadn’t included in your budget. Designing a system successfully starts with a clear understanding of what you need to build and how it needs to perform.
Introduction
A system is a collection of components that work together (to solve an input). In software engineering as in masonry(software engineers didn’t invent systems thinking), the components working together have an input and an expected output. We have bricks and cement, and we expect a wall.
Three Essentials of A System:
- Input
- Output
- Boundaries
Boundaries help prevent scope creep and contain the problem space. Without boundaries, systems are endless and we could spend infinite time going deeper, or end up with a house instead of a wall.
Over the years, I have come to appreciate albeit the hard way that the key skills in system design of a business process are: Breaking down requirements into logical steps. Thinking critically about what the needs are. Identifying what details are necessary versus what can be abstracted away.
To achieve these, we have to ask the right questions to clarify requirements before designing the system. It’s 2026, and anyone can now sit at their desk and prompt a supposed fullstack ecommerce application into existence without defining their problem and scope. Skipping this step will lead to wasted effort as nothing has been thought through or the product managed from the beginning.
From one machine, many
On a single computer, multiple threads running in the same process have access to the same address space. Therefore, data can easily be passed from one thread to another; a variable or pointer valid for one thread is also valid for another. In a distributed system, the nodes can only communicate by sending each other messages over a network since they run their own operating systems with their own address space.
Components of a Distributed System are:
- Client => Input: User actions ; Output: Server requests, UI updates
- Server => Input: Requests ; Output: Responses, server requests, DB queries, modified data
- Database => Input: Queries ; Output: Data, status responses, objects
- Load Balancer => Input: Requests ; Output: Routed requests
- Cache => Input: Keys ; Output: Cached data
The main idea around distributed systems is different locations and solving a problem. They are designed to handle failures and scale across multiple locations. When building anything, the core elements that should guide system design are:
- Translating business requirements.
- Designing the API and architecture.
- Understanding the technology and tradeoffs.
There is no perfect system, tradeoffs are necessary in light of competing priorities. To understand tradeoffs, we need to understand requirements; functional and non-functional.