Reliability
101 bites tagged Reliability — interview questions with model answers, and 60-second explainers.
Making the case for reliability over a risky feature
Quantify reliability cost in churn and revenue, show the feature's risk to existing customers, propose a sequenced path. Whether you defend strategy with data and business impact.
Prepare for a launch traffic spike
Model expected load, load-test to find the first bottleneck, scale and cache, add graceful degradation and a queue for spiky writes. capacity planning for a known surge. turning up autoscaling without finding the bottleneck.
Diagnosing intermittent crashes with PM2
PM2 auto-restarts and runs cluster mode for availability, inspect logs and metrics, watch memory for leaks, capture errors. using a process manager for resilience plus diagnosis.
Handling uncaughtException and unhandledRejection
Listen on process for uncaughtException and unhandledRejection, log the error, stop accepting new work, drain in-flight requests, then exit non-zero for a supervisor to restart. process-level last-resort error handling.
Operational versus programmer errors in Node.js
Operational errors are expected runtime conditions you handle and respond to; programmer errors are bugs that may corrupt state, so you log and gracefully restart. error classification and recovery policy.
Federating reliability ownership to product teams
Build a self-service reliability platform (golden paths, paved roads), train teams and embed SLO/on-call practices, and govern with standards plus error budget… Whether you can scale reliability by enabling teams, not gatekeeping.
Safeguards for automated remediation runbooks
Add rate limits and circuit breakers on restarts, escalate to humans after N attempts, log all actions, and check for cascading failure before acting. Whether you can build safe auto-remediation.
Designing shallow vs deep health checks
Shallow checks confirm the process is alive; deep checks verify dependencies; use shallow for liveness/load-balancer routing and deep sparingly to avoid… Whether you understand health-check semantics and failure amplification.
Conducting a Production Readiness Review
Assess monitoring and alerting, capacity and load testing, failure modes and dependencies, on-call and runbooks, and rollback or release safety. Whether you can systematically gate a launch on reliability.
Embedded vs consulting SRE engagement models
Embedded SREs sit inside one team for deep impact but limited reach; consulting SREs advise many teams broadly but shallowly. Understanding SRE team topologies and scaling. Treating either as universally best.
A team keeps blowing its error budget. First steps?
Analyze where the budget is burning via SLIs and postmortems, validate the SLO and SLIs are sound, then partner blamelessly on the top fixes. Data-driven, collaborative incident reduction.
What is an error budget and how is it used?
The budget is the allowed unreliability (100 percent minus the SLO); track its burn, ship freely when budget remains, and freeze risky changes to focus on reliability when exhausted. Understanding error budgets as a release governor.
Defining SLIs and an SLO for an auth service?
Pick user-centric SLIs like login availability and latency, measure good over valid events at the right boundary, then set an achievable SLO with a window. Translating user needs into measured reliability.
Reliability paved roads for an internal PaaS?
Built-in observability, safe deploys with health checks and rollback, sane timeouts/retries/limits, and SLO tooling. Platform thinking that makes reliability the default.
Reliability patterns for queue-based job processing?
Retries with backoff and jitter for transient faults, dead-letter queues plus a poison-message limit, idempotent handlers and visibility timeouts. Designing fault-tolerant async workers.
What is an SLO and how do you define API availability?
SLO is a target on an SLI, availability SLI is good requests over valid requests, you need labeled request counts over a window. Understanding SLI versus SLO and how to measure reliability.
Load vs stress vs soak testing
Load tests expected traffic, stress pushes past limits to find the breaking point, soak runs sustained load for hours to expose leaks. Performance-test vocabulary.
Design a centralized auto-remediation platform
Event ingestion, a rules engine mapping alerts to playbooks, a sandboxed execution runtime, and guardrails like dry-run, rate limits, and rollback. Self-healing system design.
Idempotency in infrastructure provisioning scripts
Idempotency means repeated runs converge to one end state; achieve it via desired-state reconciliation or idempotency keys with read-before-write. Safe-retry design.
Distinguishing toil from necessary ops work
Toil is manual, repetitive, automatable, tactical, and scales with growth; engineering and judgment-heavy work is not toil. Defining toil precisely. calling all ops work toil, or thinking toil means unimportant work.
Measuring post-incident review effectiveness
Track action-item completion and age, repeat-incident rate, time-to-publish, and MTTR trend. Treating the review process as a measurable system.
Fixing an unmanaged post-mortem action backlog
Generate fewer, higher-leverage items targeting systemic risk; assign owners and dates; integrate into normal planning with explicit prioritization. Making action items actually land.
Proximate cause versus root cause
Proximate cause is the immediate trigger, root cause is the systemic condition that allowed it; fix the root to prevent recurrence. Distinguishing trigger from underlying cause.
The 5 Whys root cause technique
Repeatedly ask why to move from symptom to systemic cause, stop at an actionable systemic fix. Iterative root-cause analysis. stopping at a surface symptom or treating five as a rigid count, landing on human error.
Get Reliability bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.