Preface
Thanks for your interest in Scalability Rules! This book is meant to serve as a primer, a refresher, and a lightweight reference manual to help engineers, architects, and managers develop and maintain scalable Internet products. It is laid out in a series of rules, each of them bundled thematically by different topics. Most of the rules are technically focused, while a smaller number of them address some critical mindset or process concern—each of which is absolutely critical to building scalable products. The rules vary in their depth and focus. Some rules are high level, such as defining a model that can be applied to nearly any scalability problem, while others are specific and may explain a technique, such as how to modify headers to maximize the “cache-ability” of content.
Quick Start Guide
For experienced engineers, architects, and managers read through the header sections of all the rules that contain the what, when, how, and why. You can browse through each chapter reading these, or you can jump to Chapter 13, “Rule Review and Prioritization,” which has a consolidated view of these headers. Once you’ve read these go back to the chapters that are new to you or that you find more interesting.
For less experienced readers we understand that 50 rules can seem overwhelming. We do believe that you should eventually become familiar with all the rules, but we also understand that you need to prioritize your time. With that in mind, we have picked out five chapters for managers, five chapters for software developers, and five chapters for technical operations that we recommend you read before the others to get a jump start on your scalability knowledge.
Managers:
• Chapter 1, “Reduce the Equation”
• Chapter 2, “Distribute Your Work”
• Chapter 4, “Use the Right Tools”
• Chapter 7, “Learn from Your Mistakes”
• Chapter 12, “Miscellaneous Rules”
• Chapter 1, “Reduce the Equation”
• Chapter 2, “Distribute Your Work”
• Chapter 5, “Don’t Duplicate Your Work”
• Chapter 10, “Avoid or Distribute State”
• Chapter 11, “Asynchronous Communication and Message Buses”
Technical operations:
• Chapter 2, “Distribute Your Work”
• Chapter 3, “Design to Scale Out Horizontally”
• Chapter 6, “Use Caching Aggressively”
• Chapter 8, “Database Rules”
• Chapter 9, “Design for Fault Tolerance and Graceful Failure”
As you have time later, we recommend reading all the rules to familiarize yourself with the rules and concepts that we present no matter what your role. The book is short and can probably be read in a coast-to-coast flight in the US.
After the first read, the book can be used as a reference. If you are looking to fix or re-architect an existing product, Chapter 13, “Rule Review and Prioritization,” offers an approach to applying the rules to your existing platform based on cost and the expected benefit (presented as a reduction of risk). If you already have your own prioritization mechanism, we do not recommend changing it for ours unless you like our approach better. If you don’t have an existing method of prioritization, then our method should help you think through which rules you should apply first.
If you are just starting to develop a new product, the rules can help inform and guide you as to best practices for scaling. In this case, the approach of prioritization represented in Chapter 13 can best be used as a guide to what’s most important to consider in your design. You should look at the rules that are most likely to allow you to scale for your immediate and long-term needs and implement those.
For all organizations, the rules can serve to help you create a set of architectural principles to drive future development. Select the 5, 10, or 15 rules that will help your product scale best and use them as an augmentation to your existing design reviews. Engineers and architects can ask questions relevant to each of the scalability rules that you select and ensure that any new significant design meets your scalability standards. While these rules are as specific and fixed as possible there is room for modification based on your system’s particular criteria. If you or your team has extensive scalability experience, go ahead and tweak these rules as necessary to fit your particular scenario. If you and your team are lacking large scale experience use them exactly as is and see how far they allow you to scale.
Finally, this book is meant to serve as a reference and handbook. Chapter 13 is set up as a quick reference and summary of the rules. Whether you are experiencing problems or simply looking to develop a more scalable solution, Chapter 13 can become a quick reference guide to help pinpoint the rules that will help you out of your predicament fastest or help you define the best path forward in the event of new development. Besides using this as a desktop reference also consider integrating this into your organization by one of many tactics such as taking one or two rules each week and discussing them at your technology all-hands meeting.
Why Write Another Book on Scale?
There simply aren’t many good books on scalability on the market yet, and Scalability Rules is unique in its approach in this sparse market. It is the first book to address the topic of scalability in a rules-oriented fashion. It is the first book meant to be as much of a reference as it is an overview of the topic. It includes a chapter summarizing the 50 rules and gives a prioritization of the rules for those looking to apply the book to their existing platforms.
One of our most-commented-on blog posts is on the need for scalability to become a discipline. We and the community of technologists that tackle scalability problems believe that scalability architects are needed in today’s technology organizations. In the early days of computer systems almost everyone involved was a programmer, and then came specialization with system operators, DBAs, architects, and so on. We now have many different disciplines and specialties that make up our technology teams. One of the missing disciplines is the scalability architect.
Unlike a DBA, whose job is to get things done and not necessarily teach someone else unless they are mentoring a junior DBA, one of the primary responsibilities of the scalability architect would be to educate technology people. The scalability architects should be evangelists and teachers rather than the gatekeepers of secret knowledge. As part of that teaching we’ve made a step forward by putting together these 50 rules that we believe will help guide any organization in scaling its systems.
How Did You Decide What 50 Rules to Include?
The decision of which rules to include wasn’t easy. This could easily be a book of 100 or even 200 rules. Our criteria for inclusion was to look at the recommendations that we make most often to our client base and find the most commonly recommended changes, additions, or modifications to their products. When we looked at these rules, we saw a fairly sharp drop-off in the rate of recommendations after the first 50 rules. That’s not to say that we made these 50 recommendations equally, or that the 51st potential rule wasn’t also fairly common. Rather, these 50 were just recommended more often with our clients. The rules aren’t presented in order of frequency of recommendation. In Chapter, 13 we group the rules by their benefit and priority based on how we ranked each rule’s risk reduction and cost of implementation or adoption.
How Does Scalability Rules Differ from The Art of Scalability?
The Art of Scalability (ISBN: 0137030428, published by Addison-Wesley), our first book on this topic, focused on people, process, and technology, while Scalability Rules is predominately a technically focused book. Don’t get us wrong, we still believe that people and process are the most important component of building scalable solutions. After all, it’s the organization, including both the individual contributors and the management, which succeeds or fails in producing scalable solutions. The technology isn’t at fault for failing to scale—it’s the people who are at fault for building it, selecting it, or integrating it. But we believe that The Art of Scalability adequately addresses the people and process concerns around scalability, and we wanted to go in greater depth on the technical aspects of scalability.
Scalability Rules expands on the third (technical) section of our first book. The material in Scalability Rules is either new or discussed in a more technical fashion than in The Art of Scalability. Where we discussed something in that book, we expand upon it or define it in a slightly different way to help readers better understand the concept.