This chapter covers deciding what boxes and lines represent and the steps to match requirements. It covers how to choose what to leave out, mermaid syntax, showing multiple correct answers for the same requirement (fan-out example), and how to structure a written explanation of the design.
This chapter covers how to find single points of failure and multiply out availability. Dependencies in series drag availability down; parallel redundancy pulls it up. It covers standby patterns, failover time, degraded operation, and designs that don't turn performance problems into availability problems.
This chapter derives requests per second and data volume from user count. It covers how to place peak multipliers, how the read/write ratio affects the setup, thinking in orders of magnitude, and the conditions under which "one machine is enough" holds.
This chapter explains, for junior engineers, where a database sits within the three-tier structure of a web system (user / application / data) and the role of the DBMS that connects the application to the database.
This chapter covers what replication and sharding gain and break. It explains the difference between sync and async, why you can't read what you just wrote, skew in partition keys, when eventual consistency shows up, and reading CAP as "what to give up during a partition".
Defines the functional and non-functional requirements for the fictional task management SaaS "Tasuku" used throughout this series, and explains the overall architecture built with VPC, Route 53, S3, ALB, ECS, RDS, and IAM, along with the build order based on resource dependencies.
This chapter covers vertical and horizontal — the two directions — and the steps to externalize state so horizontal is possible. It covers what load balancers distribute by and health checks, offloading reads to caches and writes to queues, and the order in which bottlenecks move.