Scalability Study Guide

📖 Core Concepts Scalability – ability of a system to handle growing work load. Horizontal (scale‑out) – add/remove nodes (e.g., servers). Vertical (scale‑up) – add/remove resources inside a single node (CPU, RAM, storage). Dimensions – administrative, functional, geographic, load, generation, heterogeneous. Strong vs. Eventual Consistency – trade‑off between a single true data version and high availability. Amdahl’s Law – speedup limited by the non‑parallel portion of a workload. Gustafson’s Law – speedup can grow linearly if problem size grows with processor count. Universal Scalability Law (USL) – models how contention and coherency affect overall capacity. --- 📌 Must Remember Horizontal scaling = adding/removing nodes; vertical scaling = adding/removing CPU/Memory/Storage on one node. Routing protocol is scalable when routing table size grows $O(\log N)$ with network nodes $N$. Amdahl’s Law: $S = \frac{1}{(1-p) + \frac{p}{P}}$. Gustafson’s Law implies speedup ≈ $P$ when workload expands with $P$. Strong consistency → one valid version across the cluster; eventual consistency → async replication, higher availability. USL parameters: contention (waiting for shared resources) and coherency (delay to make data consistent). Load scaling = ability to expand/contract to handle heavier or lighter loads. --- 🔄 Key Processes Horizontal Scaling Workflow Identify bottleneck node → provision new node(s) → configure load balancer → route traffic → monitor performance. Vertical Scaling Steps Measure resource saturation → add CPU/Memory/Storage → restart or hot‑add if supported → verify workload improvement. Applying Amdahl’s Law Determine parallel fraction $p$ → choose number of processors $P$ → compute $S$ → decide if added processors are cost‑effective. Using USL to Find Max Capacity Measure throughput at varying loads → fit USL model (throughput = $\frac{N}{1 + \alpha (N-1) + \beta N(N-1)}$) → locate $N{opt}$ where throughput peaks. --- 🔍 Key Comparisons Horizontal vs. Vertical Scaling Horizontal: adds nodes, improves fault tolerance, higher management complexity. Vertical: adds resources to one node, simpler code, limited by hardware ceiling. Strong Consistency vs. Eventual Consistency Strong: one true copy, ideal for transactions; higher latency. Eventual: async copies, higher availability; risk of stale reads. Amdahl’s Law vs. Gustafson’s Law Amdahl: fixed problem size → diminishing returns. Gustafson: problem size scales → near‑linear speedup possible. --- ⚠️ Common Misunderstandings “More CPUs always = faster” – ignores non‑parallel portion; Amdahl’s Law shows diminishing returns. Vertical scaling eliminates need for load balancing – still needed for multi‑core or multi‑process workloads. Eventual consistency is “always safe” – unsuitable for classic ACID transaction systems. Scalability = elasticity – elasticity is dynamic resizing; scalability is the potential to grow. --- 🧠 Mental Models / Intuition “Bottleneck → Add More” – picture a highway: if one lane is congested, opening a new lane (horizontal) or widening the lane (vertical) both relieve traffic, but the former also adds redundancy. Parallel Fraction Puzzle – think of a pizza: if 70 % of slices can be shared (parallel), the remaining 30 % (crust) must be eaten by one person, limiting total speedup. Consistency Trade‑off Triangle – imagine a triangle with vertices Consistency, Availability, Partition Tolerance (CAP theorem); moving toward one vertex pushes you away from the opposite. --- 🚩 Exceptions & Edge Cases Hardware Limits – vertical scaling hits CPU socket or memory channel ceilings. Network Contention – adding many nodes can increase coherence traffic, hurting performance (USL predicts a peak). Generation Scalability – newer component generations may require different drivers/APIs, breaking “plug‑and‑play”. Heterogeneous Scalability – mixing vendor components can introduce incompatibility or performance imbalance. --- 📍 When to Use Which Horizontal scaling → when you need fault tolerance, geographic distribution, or cannot upgrade a single machine (e.g., web services, HPC clusters). Vertical scaling → when the application is not distributed, licensing costs favor a single powerful server, or latency between nodes is a concern. Strong consistency → financial transactions, inventory systems, any ACID‑required DB. Eventual consistency → user‑generated content, caching, large‑scale file hosting where stale reads are tolerable. --- 👀 Patterns to Recognize $O(\log N)$ routing table growth → signals a scalable routing protocol (e.g., hierarchical routing). Speedup plateau after adding CPUs → classic Amdahl’s Law effect – look for the non‑parallel fraction. Throughput drop after certain node count → USL‑predicted contention/coherency bottleneck. Load pattern “spiky → constant” → consider horizontal scaling with auto‑scale groups. --- 🗂️ Exam Traps Choosing vertical over horizontal because “fewer machines = easier” – ignore fault‑tolerance and scalability ceiling. Assuming $S = P$ for any parallel code – forget Amdahl’s non‑parallel component. Mixing “elasticity” with “scalability” – elasticity is dynamic, scalability is the static capacity limit. Selecting strong consistency for a cache layer – will penalize latency unnecessarily. Interpreting $O(\log N)$ as “always good” – still need to examine constant factors and actual table sizes.