SRE
205 bites tagged SRE — interview questions with model answers, and 60-second explainers.
Horizontal Scaling: Add More Machines, Not Bigger Ones
Horizontal scaling (scaling out) means handling more load by adding more machines to your resource pool, not upgrading a single one. It’s used for web servers behind a load balancer. The footgun is that your app must be stateless to avoid losing user data.
Single Point of Failure: Your System's Achilles' Heel
A single point of failure (SPOF) is your system's Achilles' heel—one component whose failure causes a total outage. This is critical in high-availability design, like ensuring a website survives a server crash. The footgun is missing implicit SPOFs.
Non-Functional Requirements: How a System Should Be, Not Just What It Does
Non-Functional Requirements (NFRs) define *how well* a system performs its tasks, not *what* tasks it performs. They're the adjectives (fast, secure, reliable) for a system's verbs.
Universal Scalability Law: The Physics of Scaling
The Universal Scalability Law (USL) models throughput by quantifying the two costs of parallelism: contention and coherency. Use it to forecast performance and diagnose bottlenecks.
Queueing Theory: The Math of Waiting Lines
Queueing theory is the math of waiting lines, helping you predict system performance under load. It's used for capacity planning and setting autoscaling rules.
Critical Path Analysis for Performance Tuning
Critical path analysis finds the slowest chain of operations in a request, showing where to optimize for impact. Use it in distributed tracing to see which service call is the bottleneck. Optimizing off-path components is wasted effort.
Performance Budgets: Set Limits to Stay Fast
A performance budget is a hard limit on metrics like bundle size or load time, acting as a guardrail against regressions. It's used in CI/CD to fail builds that exceed size limits or in monitoring to alert when load times degrade.
Time-Series Forecasting: Predicting the Future from the Past
Time-series forecasting uses past data points, ordered by time, to predict future values. It's used for capacity planning and financial modeling. The footgun is assuming past trends will hold, as sudden system changes can invalidate all predictions.
Scalability Testing: Will More Hardware Fix It?
Scalability testing answers 'Will more hardware fix it?' by measuring how performance improves when you add resources. The common footgun is confusing it with load testing, which just finds the breaking point under a given load.
Soak Testing: Finding Bugs That Only Time Reveals
Soak testing is like running a marathon, not a sprint, to find bugs that only time reveals. It applies a typical production load over a long period to uncover slow memory leaks or resource exhaustion. The footgun is confusing it with stress testing.
Benchmarking: Know Your System's Limits
Benchmarking finds your system's limits by measuring its responsiveness and stability under a controlled workload. Use it to catch performance regressions, compare tech choices, or for capacity planning. The footgun: trusting benchmarks run on your laptop.
Stress Testing: Finding Your System's Breaking Point
Stress testing finds a system's breaking point by pushing it beyond normal limits. It's used for mission-critical software to test robustness and availability under extreme load, not just normal function.
Load Testing: Simulating Real-World User Traffic
Load testing answers 'Can our system handle expected traffic?' by simulating many users at once. Use it before a big launch to find bottlenecks. The footgun is confusing it with stress testing, which pushes a system past its limits to see how it breaks.
Shadow Deployment: Test in Production, Safely
Shadow deployment copies live user traffic to a new "shadow" service for testing without user impact. It's used to validate new code versions with real-world load or to analyze traffic for security threats.
Continuous Deployment: Shipping Code on Every Commit
Continuous Deployment isn't just automation; it's shipping every merged change to production automatically. It's for teams with high test coverage and robust monitoring to reduce lead time.
Quality Gates: Your Automated Release Checklist
A quality gate is an automated checklist that decides if code is ready for release. It runs in your CI pipeline, blocking merges or failing builds if metrics like code coverage or bug counts don't meet predefined standards.
Feature Flags: Ship Code Now, Release It Later
Feature flags are like light switches for your code, letting you turn features on or off in production without a new deployment. This enables canary releases and A/B tests. The main footgun is letting old flags accumulate, creating a maze of dead code.
Continuous Delivery: Ship Reliably, Anytime
Continuous Delivery (CD) makes software releases a boring, routine event. Your codebase is always in a deployable state, allowing you to ship small, incremental updates reliably and at any time. The footgun is confusing it with Continuous Deployment.
Release Candidate: The Final Dress Rehearsal
A Release Candidate (RC) is the final dress rehearsal before a software launch—a version believed to be stable enough to ship. It's used for final validation to catch show-stopping bugs.
Automated Canary Analysis: Let the Metrics Decide
Automated canary analysis uses metrics to decide if a new release is safe. It compares a new 'canary' version against the stable 'baseline' in production, scoring its health before a full rollout.
Auto-Remediation: Automated Fixes for Common Failures
Auto-remediation is a system's immune response, automatically detecting and fixing known problems like a crashed service. It's a core SRE practice for improving availability, but a bad script can create a 'remediation storm' that worsens an outage.
Executable Runbooks: Code, Not Just Checklists
An executable runbook turns a procedural document into an automated script. Instead of reading steps, you run them. It's used for incident response or maintenance, ensuring consistency. The footgun is not making them idempotent, which can worsen an outage.
Configuration Management: Enforcing Desired State
Configuration Management treats your system's setup as code to prevent "configuration drift." It's used to reliably provision servers, deploy apps, and manage fleets, ensuring every component matches its intended design and is reproducible.
Declarative vs. Imperative Automation
Declarative automation defines the desired end state (“what”), not the steps to get there (“how”). It's used in tools like Kubernetes to manage complex infrastructure, letting the system figure out the details.
Get SRE bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.