CHAPTER 1

Introduction to System Design

What it is, what makes a system good, and how to design one step by step.

Source: Chapter 1 PDF, pp. 1–7

Learning objective

Understand requirements, quality attributes, scaling choices and a repeatable framework for designing software systems.

Supplementary explanation

The problem

Two engineers design "a chat app": one builds for 1,000 users on one server, the other for 50 M concurrent users across regions. Neither is wrong until the requirements are written down.

Core PDF content

PDF page 11. What is system design? p. 1

System design is the process of deciding how different parts of a software product work together to meet user needs. Consider a chat application. Sending a message involves more than writing a function: the system must receive the request, deliver the message, store it and handle cases where the recipient is offline.

Figure 1: Simplified chat system: clients, service and shared message storage. — Figure 1. Simplified chat system: clients, service and shared message storage. · PDF p. 1

The diagram shows the basic responsibilities. A production system would also need authentication, delivery handling, network communication and failure recovery. Two common levels of design are: High-level design (HLD): How services, databases and other components fit together.  Low-level design (LLD): How the internals of a component are organized, including classes, interfaces and  algorithms. This chapter focuses on HLD.

PDF page 22. Start with requirements p. 2

Before drawing architecture diagrams, establish what the system must achieve.

Requirement type	What it answers	Chat application example
Functional	What must it do?	Send messages and support group chats.
Quality attributes	How well must it work?	Low message-delivery latency and high availability.
Constraints	What limitations must we respect?	Fixed budget, team size or required cloud platform.
Scale targets	How much demand must it handle?	A specified number of concurrent users and messages per second.

A system designed for 1,000 users may look very different from one designed for 50 million concurrent users. Neither architecture is automatically correct: the requirements determine the appropriate design.

3. What makes a system good? p. 2

These are the major quality attributes and the usual ways engineers improve them.

Attribute	Meaning	Common techniques
Scalability	Handles increasing demand.	Add servers, partition data.
Availability	Remains accessible when needed.	Redundancy, failover.
Reliability	Continues to behave correctly.	Testing, retries, recovery.
Latency	Responds within an acceptable time.	Caching, indexing, fewer network hops.
Throughput	Processes more work per unit of time.	Parallel processing, batching.
Consistency	Provides defined guarantees about the data users observe.	Transactions, coordination, replication choices.
Durability	Preserves committed data within its stated guarantees.	Replication, backups, durable storage.
Maintainability	Can be changed and operated safely.	Clear interfaces, modularity, monitoring.
Security and privacy	Protects data and controls access.	Authentication, authorization, encryption.
Cost efficiency	Delivers required capabilities within budget.	Right-sizing, efficient resource use.

These qualities can conflict. For example, adding replicas can improve availability but increase cost and create additional data-consistency decisions.

PDF page 34. The seven-step design framework p. 3

Use this framework for design discussions, architecture reviews and interviews. The order and time spent on each step depend on the problem.

Figure 2: A repeatable design framework. The process can loop back when assumptions change. — Figure 2. A repeatable design framework. The process can loop back when assumptions change. · PDF p. 3

Step	What you do	Chat application example
1. Clarify	Agree on users, features and targets.	Decide whether group chats and offline delivery are required.
2. Estimate	Calculate expected requests, storage and bandwidth.	Estimate messages per second.
3. APIs and data	Define how components communicate and what they store.	Define send-message APIs and the message data model.
4. High-level design	Map components and the request flow.	Connect clients, chat services and storage.
5. Deep dive	Investigate the hardest technical challenge.	Handle messages for offline recipients.
6. Scale and failure	Identify bottlenecks and plan recovery.	Handle server failures and growing traffic.
7. Trade-offs	Justify choices and explain their costs.	Compare simpler storage with a more distributed design.

PDF page 45. How systems evolve as demand grows p. 4

A common mistake is to start with a complex architecture before understanding the bottleneck. Systems should evolve in response to actual needs.

Figure 3: A simplified progression from one server to targeted scaling. — Figure 3. A simplified progression from one server to targeted scaling. · PDF p. 4

Problem observed	Possible design response
One server runs out of resources.	Scale up or separate application and data tiers.
Application traffic exceeds one server capacity.	Add application replicas behind a load balancer.
Frequently requested data overloads reads.	Add a cache, indexes or suitable read replicas.
Slow background work blocks user requests.	Use a queue and background workers.
One database node cannot handle the data or workload.	Evaluate partitioning or sharding.
Users experience high latency across distant regions.	Consider regional deployment and data locality.

Each solution addresses a particular problem. A cache does not automatically solve write overload, and adding application servers does not necessarily improve database capacity.

PDF page 56. Vertical vs. horizontal scaling p. 5

These are two fundamental approaches to increasing capacity.

Figure 4: Vertical scaling increases the capacity of a machine; horizontal scaling adds machines. — Figure 4. Vertical scaling increases the capacity of a machine; horizontal scaling adds machines. · PDF p. 5

	Vertical scaling (scale up)	Horizontal scaling (scale out)
How	Use a larger machine with more CPU, RAM or faster storage.	Add more machines, usually behind a load balancer or with a partitioning strategy.
Advantages	Simple to operate initially; can avoid some distributed-system complexity.	Can increase capacity and redundancy by distributing work.

	Vertical scaling (scale up)	Horizontal scaling (scale out)
Limitations	Bounded by machine capacity; a single machine can be a failure point.	Adds coordination, networking and data-management complexity.
Often useful when	Early-stage systems or components that are difficult to partition.	Stateless application services and workloads requiring additional capacity.

Horizontal scaling is particularly useful for stateless application services. It does not guarantee linear capacity growth, and databases may need separate scaling strategies.

7. Stateless vs. stateful services p. 6

Figure 5: Multiple application instances use a shared store for information that must persist between requests. — Figure 5. Multiple application instances use a shared store for information that must persist between requests. · PDF p. 6

Stateless service: Does not rely on memory retained from a previous request to process the next one. It  retrieves required information from the request or a shared store. Stateful component: Maintains relevant state, such as stored records or a persistent connection, and  therefore needs suitable handling for placement, recovery and replication.

PDF page 78. Core design principles p. 7

Principle	Practical meaning
Keep it simple	Add complexity only when the requirements justify it.
Design for failure	Plan for components and networks to fail.
Prefer stateless application services	Make instances easier to replace and scale.
Separate responsibilities	Give components clear roles and interfaces.
Make retries safe	Use idempotency where duplicate requests could cause unwanted effects.
Protect the system	Apply timeouts, rate limits and appropriate access controls.
Measure before optimizing	Use metrics to identify bottlenecks rather than guessing.

9. Check your understanding p. 7

Choose an answer, then review the answer and rationale in the right column.

Question	Answer and rationale
1. Message delivery must be under 300 ms at p99. What type of requirement is it? A. Functional requirement B. Quality attribute target C. Constraint	Answer: B - Quality attribute target. It describes how well the system should perform.
2. Application servers are overloaded, but database load is low. What is a reasonable first option? A. Add application capacity and distribute requests B. Shard the database C. Move to multiple regions	Answer: A - Add application capacity. The evidence points to application capacity, not a database or regional bottleneck.
3. What follows clarifying requirements in the seven-step framework? A. Deep dive B. Estimate scale C. High-level design	Answer: B - Estimate scale. Estimate demand before committing to an architecture.
4. Why use a queue for sending emails? A. Store every user profile B. Run slow work outside the request path C. Guarantee no component fails	Answer: B - Run slow work outside the request path. A queue decouples background work; reliability still needs additional design.

Chapter recap p. 7

Remember: System design begins with requirements, not technologies. Define what the product must do, establish quality targets and constraints, and start with the simplest solution that fits. Add complexity only when workload or failure risks justify it. The goal is not to draw the most boxes. It is to make clear, defensible engineering decisions that meet user needs at the required scale and cost.

Program / product lens Supplementary

Requirements and SLOs are the contract between product, engineering and operations. A TPM should make the out-of-scope list and the non-functional targets explicit before any architecture review.

Recap

Requirements come first: functional (what), non-functional (how well), constraints (what is fixed).
Quality attributes trade against each other; name the lever you pull and what it costs.
The seven steps — clarify, estimate, API & data model, high-level design, deep dive, scale & failure, trade-offs — fit any problem.
Scale in stages: each step (replicas, cache, sharding, async) exists to remove a specific bottleneck.

Check your understanding

1. "p99 delivery under 300 ms" is which kind of requirement?
2. "Must run on AWS with a team of 8" is a…
3. In the seven-step framework, what comes immediately after clarifying requirements?
4. Your read-heavy service's single database is at 90% CPU. Which first step targets that specific bottleneck?

Try it

Open “Blank canvas” in Labs Web / mobile client Application / API service EC2 (Auto Scaling)Compute Engine (MIG)Virtual Machine Scale Sets App Service

References

Chapter 1 PDF, pp. 1–7; figures 1, 2, 3, 4, 5.

Ch. 2: Networking and Communication Fundamentals

Tip: use ← and → keys to move between chapters.