System Design Basics

Understand the problem before drawing the architecture

System Design does not start with choosing a database, queue, or cache. First, you need to understand what the system must do, which properties matter to it, and which constraints will affect the decisions. Only then do individual components start forming a meaningful architecture.

In this section, we will build the basic set of concepts needed in almost any system design problem. There will be no ready-made “perfect architecture” here — instead, you will get a consistent way to reason about a system.

What we will cover

• Design Process. We will learn how to move from the problem statement to a high-level system diagram and check the solution for weak points.
• Functional Requirements. We will see how to capture the actions and scenarios the system must support.
• Non-Functional Requirements. We will look at speed, scalability, availability, and other properties that determine the quality of a system.
• Latency and Throughput. We will separate two different questions: how quickly one request completes and how much work the system can process per unit of time.
• Availability and Reliability. We will understand how “the service responds right now” differs from “the system works correctly and predictably.”
• Stateless and Stateful. We will see where system state lives and why that directly affects scalability and fault tolerance.
• Architecture Trade-offs. We will learn to look at a decision not as a list of benefits, but as an exchange of one system property for another.

These topics form one chain: requirements define the goal, metrics make it measurable, state shapes the components, and trade-offs explain why different systems arrive at different architectures. Once this foundation is in place, the next step is to estimate real workload.