You are previewing Scalability Rules: Principles for Scaling Web Sites, Second Edition.
O'Reilly logo
Scalability Rules: Principles for Scaling Web Sites, Second Edition

Book Description

Fully updated! Fifty Powerful, Easy-to-Use Rules for Supporting Hyper Growth

“Whether you’re taking on a role as a technology leader in a new company or you simply want to make great technology decisions, Scalability Rules will be the go-to resource on your bookshelf.” –Chad Dickerson, CTO, Etsy

Scalability Rules, Second Edition, is the easy-to-use scalability primer and reference for every architect, developer, network/software engineer, web professional, and manager. Authors Martin L. Abbott and Michael T. Fisher have helped scale hundreds of high-growth companies and thousands of systems. Drawing on their immense experience, they present 50 up-to-the-minute technical best practices for supporting hyper growth practically anywhere.

Fully updated to reflect new technical trends and experiences, this edition is even easier to read, understand, and apply. Abbott and Fisher have also added powerful “stories behind the rules”: actual experiences and case studies from CTOs and technology executives at Etsy, NASDAQ, Salesforce, Shutterfly, Chegg, Warby Parker, Twitter, and other scalability pioneers.

Architects will find powerful technology-agnostic insights for creating and evaluating designs. Developers will discover specific techniques for handling everything from databases to state. Managers will get invaluable help in setting goals, making decisions, and interacting with technical teams. Whatever your role, you’ll find practical risk/benefit guidance for setting priorities, translating plans into action, and gaining maximum scalability at minimum cost.

You’ll learn how to

  • Simplify architectures and avoid “over-engineering”

  • Design scale into your solution, so you can scale on a just-in-time basis

  • Make the most of cloning and replication

  • Separate functionality and split data sets

  • Scale out, not up

  • Get more out of databases without compromising scalability

  • Eliminate unnecessary redirects and redundant double-checking

  • Use caches and CDNs more aggressively, without unacceptable complexity

  • Design for fault tolerance, graceful failure, and easy rollback

  • Emphasize statelessness, and efficiently handle state when you must

  • Effectively utilize asynchronous communication

  • Learn from your own mistakes and others’ high-profile failures

  • Prioritize your actions to get the biggest “bang for the buck”

  • Table of Contents

    1. About This E-Book
    2. Title Page
    3. Copyright Page
    4. Praise for the First Edition of Scalability Rules
    5. Dedication Page
    6. Contents
    7. Preface
      1. Taming the Wild West of the Internet
      2. Quick Start Guide
      3. Why a Second Edition?
      4. How Does Scalability Rules Differ from The Art of Scalability?
      5. Notes
    8. Acknowledgments
    9. About the Authors
    10. 1. Reduce the Equation
      1. Rule 1—Don’t Overengineer the Solution
      2. Rule 2—Design Scale into the Solution (D-I-D Process)
        1. Design
        2. Implement
        3. Deploy
      3. Rule 3—Simplify the Solution Three Times Over
        1. How Do I Simplify My Scope?
        2. How Do I Simplify My Design?
        3. How Do I Simplify My Implementation?
      4. Rule 4—Reduce DNS Lookups
      5. Rule 5—Reduce Objects Where Possible
      6. Rule 6—Use Homogeneous Networks
      7. Summary
      8. Notes
    11. 2. Distribute Your Work
      1. Rule 7—Design to Clone or Replicate Things (X Axis)
      2. Rule 8—Design to Split Different Things (Y Axis)
      3. Rule 9—Design to Split Similar Things (Z Axis)
      4. Summary
      5. Notes
    12. 3. Design to Scale Out Horizontally
      1. Rule 10—Design Your Solution to Scale Out, Not Just Up
      2. Rule 11—Use Commodity Systems (Goldfish Not Thoroughbreds)
      3. Rule 12—Scale Out Your Hosting Solution
      4. Rule 13—Design to Leverage the Cloud
      5. Summary
      6. Notes
    13. 4. Use the Right Tools
      1. Rule 14—Use Databases Appropriately
      2. Rule 15—Firewalls, Firewalls Everywhere!
      3. Rule 16—Actively Use Log Files
      4. Summary
      5. Notes
    14. 5. Get Out of Your Own Way
      1. Rule 17—Don’t Check Your Work
      2. Rule 18—Stop Redirecting Traffic
      3. Rule 19—Relax Temporal Constraints
      4. Summary
      5. Notes
    15. 6. Use Caching Aggressively
      1. Rule 20—Leverage Content Delivery Networks
      2. Rule 21—Use Expires Headers
      3. Rule 22—Cache Ajax Calls
      4. Rule 23—Leverage Page Caches
      5. Rule 24—Utilize Application Caches
      6. Rule 25—Make Use of Object Caches
      7. Rule 26—Put Object Caches on Their Own “Tier”
      8. Summary
      9. Notes
    16. 7. Learn from Your Mistakes
      1. Rule 27—Learn Aggressively
      2. Rule 28—Don’t Rely on QA to Find Mistakes
      3. Rule 29—Failing to Design for Rollback Is Designing for Failure
      4. Summary
      5. Notes
    17. 8. Database Rules
      1. Rule 30—Remove Business Intelligence from Transaction Processing
      2. Rule 31—Be Aware of Costly Relationships
      3. Rule 32—Use the Right Type of Database Lock
      4. Rule 33—Pass on Using Multiphase Commits
      5. Rule 34—Try Not to Use Select for Update
      6. Rule 35—Don’t Select Everything
      7. Summary
      8. Notes
    18. 9. Design for Fault Tolerance and Graceful Failure
      1. Rule 36—Design Using Fault-Isolative “Swim Lanes”
      2. Rule 37—Never Trust Single Points of Failure
      3. Rule 38—Avoid Putting Systems in Series
      4. Rule 39—Ensure That You Can Wire On and Off Features
      5. Summary
    19. 10. Avoid or Distribute State
      1. Rule 40—Strive for Statelessness
      2. Rule 41—Maintain Sessions in the Browser When Possible
      3. Rule 42—Make Use of a Distributed Cache for States
      4. Summary
      5. Notes
    20. 11. Asynchronous Communication and Message Buses
      1. Rule 43—Communicate Asynchronously as Much as Possible
      2. Rule 44—Ensure That Your Message Bus Can Scale
      3. Rule 45—Avoid Overcrowding Your Message Bus
      4. Summary
    21. 12. Miscellaneous Rules
      1. Rule 46—Be Wary of Scaling through Third Parties
      2. Rule 47—Purge, Archive, and Cost-Justify Storage
      3. Rule 48—Partition Inductive, Deductive, Batch, and User Interaction (OLTP) Workloads
      4. Rule 49—Design Your Application to Be Monitored
      5. Rule 50—Be Competent
      6. Summary
      7. Notes
    22. 13. Rule Review and Prioritization
      1. A Risk-Benefit Model for Evaluating Scalability Projects and Initiatives
      2. 50 Scalability Rules in Brief
        1. Rule 1—Don’t Overengineer the Solution
        2. Rule 2—Design Scale into the Solution (D-I-D Process)
        3. Rule 3—Simplify the Solution Three Times Over
        4. Rule 4—Reduce DNS Lookups
        5. Rule 5—Reduce Objects Where Possible
        6. Rule 6—Use Homogeneous Networks
        7. Rule 7—Design to Clone or Replicate Things (X Axis)
        8. Rule 8—Design to Split Different Things (Y Axis)
        9. Rule 9—Design to Split Similar Things (Z Axis)
        10. Rule 10—Design Your Solution to Scale Out, Not Just Up
        11. Rule 11—Use Commodity Systems (Goldfish Not Thoroughbreds)
        12. Rule 12—Scale Out Your Hosting Solution
        13. Rule 13—Design to Leverage the Cloud
        14. Rule 14—Use Databases Appropriately
        15. Rule 15—Firewalls, Firewalls Everywhere!
        16. Rule 16—Actively Use Log Files
        17. Rule 17—Don’t Check Your Work
        18. Rule 18—Stop Redirecting Traffic
        19. Rule 19—Relax Temporal Constraints
        20. Rule 20—Leverage Content Delivery Networks
        21. Rule 21—Use Expires Headers
        22. Rule 22—Cache Ajax Calls
        23. Rule 23—Leverage Page Caches
        24. Rule 24—Utilize Application Caches
        25. Rule 25—Make Use of Object Caches
        26. Rule 26—Put Object Caches on Their Own “Tier”
        27. Rule 27—Learn Aggressively
        28. Rule 28—Don’t Rely on QA to Find Mistakes
        29. Rule 29—Failing to Design for Rollback Is Designing for Failure
        30. Rule 30—Remove Business Intelligence from Transaction Processing
        31. Rule 31—Be Aware of Costly Relationships
        32. Rule 32—Use the Right Type of Database Lock
        33. Rule 33—Pass on Using Multiphase Commits
        34. Rule 34—Try Not to Use Select for Update
        35. Rule 35—Don’t Select Everything
        36. Rule 36—Design Using Fault-Isolative “Swim Lanes”
        37. Rule 37—Never Trust Single Points of Failure
        38. Rule 38—Avoid Putting Systems in Series
        39. Rule 39—Ensure That You Can Wire On and Off Features
        40. Rule 40—Strive for Statelessness
        41. Rule 41—Maintain Sessions in the Browser When Possible
        42. Rule 42—Make Use of a Distributed Cache for States
        43. Rule 43—Communicate Asynchronously as Much as Possible
        44. Rule 44—Ensure That Your Message Bus Can Scale
        45. Rule 45—Avoid Overcrowding Your Message Bus
        46. Rule 46—Be Wary of Scaling through Third Parties
        47. Rule 47—Purge, Archive, and Cost-Justify Storage
        48. Rule 48—Partition Inductive, Deductive, Batch, and User Interaction (OLTP) Workloads
        49. Rule 49—Design Your Application to Be Monitored
        50. Rule 50—Be Competent
      3. A Benefit/Priority Ranking of the Scalability Rules
        1. Very High—1
        2. High—2
        3. Medium—3
        4. Low—4
        5. Very Low—5
      4. Summary
    23. Index
    24. Code Snippets