Errata

System Design on AWS

Errata for System Design on AWS

Submit your own errata for this product.

The errata list is a list of errors and their corrections that were found after the product was released. If the error was corrected in a later version or reprint the date of the correction will be displayed in the column titled "Date Corrected".

The following errata were submitted by our customers and approved as valid errors by the author or editor.

Color key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted By Date submitted Date corrected
Page Chapter 2, Data Storage Format, File-Based Storage
1st paragraph of the File-Based Storage section

The last sentence of the first paragraph of the "File-Based Storage" section reads "File-based storage is commonly used for storing structured data, such as documents, images, videos, and audio files." I believe this should be "unstructured data", as those file formats are generally considered to be unstructured.

Note from the Author or Editor:
remove the "structured" word from the line. Update the line to "... used for storing data, such as documents ....."

Mark Côté  Feb 25, 2025 
Page Chapter 2, Open Source Relational Database Systems, PostgreSQL
3rd paragraph in PostgreSQL section, after the Features bullet list

In the second sentence of the paragraph starting with "MySQL and PostgreSQL are compared in Table 2-1", "ACID-compliant" is misspelled as "ACID-complaint".

Note from the Author or Editor:
fix the spelling.

Mark Côté  Feb 25, 2025 
Page xiii
2nd paragraph, 6th line

“I hope the you grasp these concepts and are inspired to build…”

Error: “hope the you”

Note from the Author or Editor:
Grammatical correction, keeping this is O'Reilly bucket if we can update the Foreword. from "the" to "that"

William Martín Chávez González   Mar 26, 2025 
Page Chapter 6
Section on UDP

The book says 'A sender sends a UDP segment to a destination on a specific port.'

In the context of UDP, the correct term is datagram, not "segment."

Note from the Author or Editor:
Makes sense. We should update the term "segment" with "datagram". This should be done for entire "User Datagram Protocol" section
1. holds the minimum data for segment delivery -> datagram delivery
2. order of segments -> order of datagrams
3. A sender sends a UDP segment -> A sender sends a UDP datagram

Saraf  May 02, 2025 
Page Chapter 6
GraphQL

In the example ...

type FoodItem {
id: String!
name: String!
rating: Float
isVeg: Boolean!
}
query {
Restaurant (id: “lsoa34444lsoa”) {
name
foodItems {
name
description
}
}
}

Here - FoodItem does not have a 'description' attribute.
In GraphQL, queries are strongly typed and validated against the schema before they are executed. If you request a field (like description) that isn't defined in the type (FoodItem), the query is invalid and will return an error like:
The query will fail with 'Cannot query field "description" on type "FoodItem".'

Either the FoodItem type should have 'description' attribute, or 'description' should be removed from the query.

Note from the Author or Editor:
query to be updated (replace description with rating) -

query {
Restaurant (id: "lsoa34444lsoa") {
name
foodItems {
name
rating
}
}
}

saraf  May 02, 2025 
Page Chapter 8
Solution Architecture → Monoliths

It says 'Monoliths are straightforward to develop, test, deploy, and scale horizontally since they are a single executable or deployment unit.'

The statement that "monoliths are straightforward to scale horizontally" is misleading.

Monolithic architectures are generally easier to scale vertically—by upgrading the hardware (CPU, RAM, etc.) on a single server running the entire application. This is because all components are tightly coupled and reside within a single codebase and deployment unit, making it challenging to distribute the load across multiple servers.

Horizontal scaling—adding more servers or nodes—can be done with monoliths, but it is much more difficult and less efficient compared to microservices. For a monolith to scale horizontally, it must be stateless and designed to handle distributed workloads, which is uncommon and often complex to implement. In practice, most monoliths are not built this way, so horizontal scaling is limited and resource-intensive.

Microservices architectures, by contrast, are designed for horizontal scaling. Each independent service can be scaled out as needed, allowing for more efficient use of resources and better handling of variable loads across the system.

So, while monoliths are straightforward to develop and deploy, they are not inherently easy to scale horizontally. Horizontal scaling is a key advantage of microservices, not monoliths.

Note from the Author or Editor:
Update the statement --
"monoliths are straightforward to scale horizontally" to "monoliths are straightforward to scale vertically"

Saraf  May 20, 2025 
Page Chapter 9
Section on Subnets

The problematic sentence is:
"A subnet with resources having a public IPv4 address but no direct route to the internet gateway is called a private subnet."
What's Wrong?

Contradicts AWS Fundamentals:

A subnet is defined as private based only on its route table (absence of a route to an Internet Gateway).

Public IPv4 addresses are irrelevant to the subnet's public/private classification.

Misleading Implication:

It suggests that assigning a public IP to a resource could make a subnet "private," which is incorrect.

Resources in private subnets should never have public IPv4 addresses (they use private IPs only).

Security Risk:

If a resource in a private subnet has a public IP but no route to IGW, the IP is useless and unreachable, violating AWS security best practices.

Why the Sentence is Inaccurate

Private subnets must:

Have no IGW route in their route table.

Use only private IPs (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

Assigning a public IP to a resource in a private subnet:

Is technically possible but functionally broken.

Violates the purpose of private subnets (isolation from public internet).

The only factor determining a subnet's public/private status is its route table, not the IPs of its resources. Mixing public IPs with private subnets creates confusion and security gaps. Always:

Use public IPs only in public subnets.

Use private IPs only in private subnets.

Corrected Sentence

"A subnet with no direct route to the internet gateway is called a private subnet. Resources in it must use private IPv4 addresses."

Note from the Author or Editor:
Update the statement as suggested - A subnet with no direct route to the internet gateway is called a private subnet. Resources in it must use private IPv4 addresses.

Saraf  Jun 07, 2025 
Page Chapter 9
Internet Connectivity -> Route Tables

Problem statement: “A route table in AWS defines network traffic both in and out of a subnet.”

---

What’s Wrong with This Clause?

1. Route Tables Only Affect Outbound Traffic

- *AWS Route Tables* control how *outbound traffic* (traffic leaving resources in the subnet) is routed.
- When a resource in the subnet initiates a connection, the route table determines where the packet goes (e.g., to the internet gateway, NAT gateway, or another subnet).
- *Inbound traffic* (traffic coming from outside to the subnet) is *not controlled by the subnet’s route table*. Instead, it is controlled by:
- The route table of the destination subnet (for traffic originating within the VPC)
- The presence of a public IP and a route to the IGW (for internet traffic)
- *Security groups* and *network ACLs* (NACLs) for packet filtering

2. Inbound Traffic Is Determined by Other Factors

- For traffic from the internet, the *return path* is established only if:
- The resource has a public IP/Elastic IP
- The subnet has a route to the IGW
- Security group and NACL rules allow it
- The route table does *not* determine whether unsolicited inbound internet traffic can reach a resource.

3. Example

- If you have a web server in a public subnet with a public IP:
- Outbound: When the server sends traffic to the internet, the route table directs it to the IGW.
- Inbound: When a user tries to access your web server, AWS’s infrastructure routes the packet to your public IP, and the IGW delivers it to your subnet. The route table is not consulted for this inbound path; instead, security groups/NACLs are checked.

---
Suggested:
Route tables in AWS only control outbound traffic from a subnet, not inbound traffic.
(Inbound access is managed by security groups, NACLs, and whether the resource has a public IP and a route to the IGW.)

Note from the Author or Editor:
Remove this sentence entirely from the paragraph for clarity --

"Route tables direct network traffic in and out of a subnet, but they don’t apply any security filters on this traffic. "

Saraf  Jun 07, 2025 
Page Chapter 9
AWS Elastic Load Balancer

Problem sentence:
"Network load balancer (NLB)
Operates at the network layer (L4) for TCP, UDP, and TLS protocols"

L4 is the Transport Layer. 'network layer (L4)' should be replaced with 'transport layer (L4)'

Note from the Author or Editor:
Update the statement -

Operates at the fourth layer of OSI model supporting TCP, UDP, TCP_UDP, TLS, QUIC, and TCP_QUIC protocols.

Saraf  Jun 09, 2025 
Page Chapter 10
Amazon Simple Storage Service --> S3 Storage Classes

'AWS recommends the S3 storage class over reduced redundancy as it is more cost-effective.' I sense that something is missing here. Which S3 storage class does AWS recommend over reduced redundancy?
The word 'Standard' is missing.

The sentence should perhaps read -
'AWS recommends the S3 Standard storage class over reduced redundancy as it is more cost-effective.'

Note from the Author or Editor:
Yes, this should be updated to include 'Standard' keyword for clarity.

Saraf  Jun 09, 2025 
Page Forward
page number 8, 2nd last paragraph

statement is :

I hope the
you grasp these concepts and are inspired to build similarly
amazing products and services that delight their customers.



it should be :
I hope "that" you grasp these concepts and are inspired to build similarly amazing products and services that delight your customers.

Note from the Author or Editor:
Production copy team can take a call if this needs to updated.

Sumant Devnath Khapre  Jun 17, 2025 
Page 2. Storage Types and Relation Stores
Under AICD - Durability

'Durability guarantees ensure that once a transaction is committed, its changes are permanently stored and will survive system failures such as crashes or power outages. '

should be

'Durability guarantees that once a transaction is committed, its changes are permanently stored and will survive system failures such as crashes or power outages. '

Note from the Author or Editor:
update the language

Nollie Chen  Sep 03, 2024  Feb 14, 2025