Reliability, Observability, and Incident Response Questions
Covers designing, building, and operating systems to be reliable, observable, and resilient, together with the operational practices for detecting, responding to, and learning from incidents. Instrumentation and observability topics include selecting and defining meaningful metrics and service level objectives and service level agreements, time series collection, dashboards, structured and contextual logs, distributed tracing, and sampling strategies. Monitoring and alerting topics cover setting effective alert thresholds to avoid alert fatigue, anomaly detection, alert routing and escalation, and designing signals that indicate degraded operation or regional failures. Reliability and fault tolerance topics include redundancy, replication, retries with idempotency, circuit breakers, bulkheads, graceful degradation, health checks, automatic failover, canary deployments, progressive rollbacks, capacity planning, disaster recovery and business continuity planning, backups, and data integrity practices such as validation and safe retry semantics. Operational and incident response practices include on call practices, runbooks and runbook automation, incident command and coordination, containment and mitigation steps, root cause analysis and blameless post mortems, tracking and implementing action items, chaos engineering and fault injection to validate resilience, and continuous improvement and cultural practices that support rapid recovery and learning. Candidates are expected to reason about trade offs between reliability, velocity, and cost and to describe architectural and operational patterns that enable rapid diagnosis, safe deployments, and operability at scale.
EasyTechnical
57 practiced
Explain graceful degradation for a feature-rich web application. Provide a concrete design where, under partial overload, essential features remain available while expensive features are temporarily disabled. Include how you'd detect overload and implement user-facing messaging.
Sample Answer
Requirements & constraints:- Keep core user flows (login, read content, checkout) available under load.- Disable expensive, non-essential features (personalized recommendations, high-res image processing, real-time analytics) temporarily.- Provide clear, localized user messaging and automated recovery.High-level design:- API Gateway → Auth & Routing → Microservices (Core services: Auth, Content, Checkout) + Expensive services (Recommender, Image Processor, Real-time Feed).- Supporting components: Redis cache, Feature Flag/Config Service, Rate Limiter, Circuit Breakers, Metrics & Alerting (Prometheus/Grafana), Traffic Shaper, Message Queue for async work.How graceful degradation works:1. Detection- SLO-based alerts: increase in p95/p99 latency, error-rate spike, CPU/memory > threshold, request queue length or backlog in message queues.- Application-level signals: circuit-breaker trips on downstream failures; health-checks return degraded state.- Combine signals into a global “overload score” in the orchestrator (API Gateway or control plane).2. Decision & enforcement- When overload score crosses threshold, orchestrator flips targeted feature flags and adjusts routing: - Disable/route expensive features to degraded endpoints (e.g., Recommender → return cached/top-popular items). - Reduce image quality via CDN parameter or serve pre-generated low-res images. - Convert synchronous expensive calls to async: accept request, enqueue background job, and return lightweight placeholder. - Apply rate limits per user or per feature (token bucket) to protect core services.3. User-facing messaging- UX components read the feature-availability flag and render contextual, friendly messages: - Inline notice example: “Personalized recommendations are temporarily limited to improve site performance — try popular items.” - Non-blocking banner: “We’re operating in reduced mode to keep checkout fast. Some features may be limited.” - For async operations: show progress states (“We’ll email you when high-res images are ready.”)- Messages are localized, brief, and provide CTA or recovery expectation (e.g., “Normal service expected in <5 minutes”).Implementation details and trade-offs:- Use a centralized Feature Flag service (e.g., LaunchDarkly or homegrown) with low-latency SDKs so toggles take effect immediately.- Circuit breakers (Hystrix-like) isolate failing services and trigger degradations.- Cache popular responses in Redis/CDN so degraded paths still provide useful content.- Prefer progressive degradation: turn off least-impactful expensive features first, monitor SLOs, then escalate.- Trade-off: reduced personalization vs. kept availability — acceptable for user trust and revenue protection.Monitoring & recovery:- Auto-recovery rules: when overload score returns to safe range and services healthy for N minutes, gradually re-enable features (canary rollouts).- Log events for postmortem and tune thresholds.This design preserves essential flows by isolating and throttling expensive subsystems, provides automatic detection and targeting via feature flags and circuit breakers, and communicates clearly to users so UX remains trustworthy under partial overload.
HardTechnical
50 practiced
A cascading failure caused by a schema change has led to data corruption across regions and customer-facing outages. As the Solutions Architect guiding recovery, outline a step-by-step incident response: immediate containment, scope identification, data recovery strategy, customer communication plan, and long-term safeguards to prevent recurrence.
Sample Answer
Immediate containment- Put the system into safe mode: disable writes to affected services via feature flags or routing rules; set affected DBs to read-only where safe.- Stop any automated deploys or migrations and revoke deployment tokens for the change.- Activate the incident response runbook and assemble the response team: engineering (DB, app), SRE, product, legal/comms, and sales/CS.Scope identification- Identify the exact schema change, migration scripts, and the time window deployed.- Use audit logs, deploy metadata, and CDC streams to list affected tables, regions, and clusters.- Run quick integrity queries (row counts, checksums) and detect divergence across replicas/regions.- Prioritize customers/systems by ROI/impact (payment, auth, high SLAs).Data recovery strategy- If a clean pre-change snapshot exists: perform region-by-region restore to isolated recovery clusters; validate with checksums before reintroducing data.- If only WAL/CDC available: perform point-in-time recovery (PITR) to just before the change and replay safe transactions; or use logical replication to roll back or roll forward corrective scripts.- For partially corrupted rows, build idempotent repair jobs that reconcile from canonical sources (master region or source-of-truth).- Test recovery on staging with representative data; run end-to-end smoke tests and data validation before promoting.- Implement phased cutover: serve a subset of traffic, monitor, then full.Customer communication plan- Immediately notify affected customers with incident severity, impact, and mitigation steps; give expected next update times.- Use multi-channel comms: status page, email to account owners, customer success outreach for high-touch customers.- Provide transparent updates: what happened, who’s impacted, ETA for fix, and mitigation steps customers can take.- After recovery, send post-incident report and remediation timeline; offer compensations as per SLA where appropriate.Long-term safeguards- Harden schema-change process: require backward/forward-compatible migrations, zero-downtime patterns, and explicit review gates.- Enforce automated pre-deploy checks: synthetic tests, multi-region integration tests, data-migration dry-runs, and schema-change safety linter.- Use canary deployments for DB migrations and run migration in read-only mode first; add feature flags to toggle new behavior.- Improve observability: add schema-change alarms, replication divergence monitors, and per-customer anomaly detectors.- Update runbooks, add RBAC controls for migrations, require pair sign-off for production schema changes, and schedule regular disaster-recovery drills.- Commit to a blameless postmortem with timelines, root cause, owners for each remediation, and measurable verification for each action.
HardTechnical
57 practiced
Propose a continuous chaos engineering program across production that provides measurable improvements in resilience without jeopardizing customers. Describe experiment selection criteria, scheduling, guardrails, blast-radius controls, automation, and how to measure that chaos engineering activities reduced incident frequency or MTTR.
Sample Answer
Requirements & goals:- Improve production resilience continuously while keeping customer impact ≤ negligible.- Measure reduction in incident frequency and MTTR; enable safe, automated experiments integrated with CI/CD.Program overview (high-level):- Continuous, progressive chaos pipeline: Canary experiments → Controlled production experiments → Business-impact-aware experiments.- Ownership: SRE leads experiments; Solutions Architect designs boundaries and platform-level automations; engineering owns service-specific hypotheses.Experiment selection criteria:- Business priority alignment (customer-facing services first)- Hypothesis-driven: clear H0/H1 (e.g., “If DB replica fails, failover completes within SLA”)- Observability maturity (logs, traces, metrics, alerts present)- Risk score (customer impact, criticality, undoability) — only low/medium risk initialScheduling:- Quiet windows + business-aware calendars; start with low-traffic hours- Gradual ramp: synthetic (staging) → narrow blast radius in production → wider if metrics stable- Automated pacing rules: weekly small experiments, monthly wider exercises, quarterly large-domain drillsGuardrails & blast-radius controls:- Preflight checks: health thresholds, monitoring presence, rollback playbook- Automated kill-switch: immediate abort if latency/error/traffic anomalies cross thresholds- Traffic isolation: route small percentage of traffic to experiment instances (traffic shadowing, feature flags)- Resource quotas & rate limits to prevent cascading resource exhaustion- Read-only or throttled fault injection where possibleAutomation:- Infrastructure-as-code templates for experiment definitions- CI hooks: run canary chaos as part of release pipelines- Use orchestration tools (Litmus, Chaos Mesh, Gremlin) integrated with CI/CD and monitoring (Prometheus, Tempo, ELK)- Auto-validate preconditions, run experiment, collect telemetry, auto-rollback on guardrail breach- Store experiments, outcomes, and runbooks in a centralized catalog for reuseMeasuring impact (evidence of improvement):- Baseline and continuous metrics: - Incident frequency per service (incidents/week) pre/post program - MTTR (mean time to recovery) per incident type - Healthy SLA/SLO breach count - Time-to-detect (TTD) and time-to-remediate (TTR)- Controlled A/B evaluation: run experiments on a subset of services/orgs and compare incident trends vs control group over 3–6 months- KPI definitions: aim for X% reduction in P1 incident frequency, Y% MTTR improvement within 6 months- Postmortems and learning loop: every failed test or real incident leads to a remediation ticket, runbook update, and retestGovernance & culture:- Executive-backed chaos policy, safety committee approvals for high-risk tests- Training and tabletop drills for SRE/ops on rollback/runbooks- Quarterly reviews with stakeholders showing metrics, learnings, and risk-adjusted ROITrade-offs & safeguards:- Start conservative to build confidence; expand scope as observability and automation mature- Balance frequency vs risk: more frequent small tests yield steady improvement with lower customer riskThis program ensures measurable resilience gains (reduced incidents and MTTR) while minimizing customer exposure via progressive ramps, automated guardrails, and rigorous measurement.
HardSystem Design
86 practiced
Architect a multi-region, highly-available system for a global e-commerce platform required to maintain 99.99% uptime and survive single region failures. Describe replication strategies for stateful data, consistency model choices (strong vs eventual), failover mechanisms, traffic routing, and how to validate the design with tests.
Sample Answer
Requirements & constraints:- Global e‑commerce: 99.99% uptime (~52 min/year), survive single-region failure, low read latency worldwide, acceptable write latencies, PCI/PII compliance.High-level architecture:- Active-active multi-region deployment (at least 3 regions across different AZs/continents).- Edge: Global CDN + WAF + rate limiting.- Global ingress: Anycast/Global Accelerator + geo-aware DNS (Route53/GSLB) for fast failover.- Region clusters: stateless app servers behind regional ALBs, regional caches, message buses, and stateful storage with cross-region replication.- Control plane: central orchestrator for runbooks, health aggregation, and deployment coordination.Stateful data & replication:- User sessions/cart (session affinity acceptable): store in regional Redis clusters with active-active replication using CRDTs or Redis Enterprise Active-Active (conflict-free merges). TTLs + periodic reconciliation.- Orders/payments (critical, ACID): masterless or single-writer per global shard. Use a globally-distributed transactional database (CockroachDB / Spanner / Yugabyte) for strong consistency where needed; or use per-region primary with synchronous replication for payment ledger if using RDBMS (limited to regions with low write latency) and async replicas elsewhere.- Product/catalog (reads heavy): primary in one region, multi-master async replication to others with versioned objects and last-write-wins plus background reconciliation; use CDN for static content.- Event store/analytics: append-only in each region, async replication to central lake (S3) for batch processing.Consistency model choices:- Strong consistency for payments, inventory decrement, and anything that must be linearizable (use distributed transactions or single-writer shards).- Eventual consistency for product catalog, personalization, and non-critical user metadata to prioritize availability and low read latency.- Use read-your-writes and session guarantees where UX requires consistency (e.g., show added item in cart).Failover mechanisms & traffic routing:- Health checks at multiple layers: app, DB, dependency probes. Use orchestration to mark region healthy/unhealthy.- DNS/Anycast with low TTLs + health-based routing to steer traffic away. Global load balancer (GCP/ALB/GSLB) to perform regional failover quickly.- For stateful failover: - Strong-store: implement leader election (etcd/consensus) with automatic failover; preconfigured promotion timelines and circuit breakers to avoid split-brain. - Session/cart: fallback to degraded read-only mode or reconstruct from last-known state plus accept write operations into local queue with guaranteed-at-least-once delivery to reconciliation pipeline.- Data plane: use change-data-capture + idempotent consumers to replay mutations during recovery.Operational considerations:- Backups: continuous incremental backups + point-in-time recovery; cross-region replicated snapshots.- Runbooks & automation: scripted failover, rollback, and smoke tests; playbooks for manual approval where needed.- Security: encryption at rest/in-transit, KMS replicated, compliance audits.Validation & testing:- Chaos engineering: region kill, AZ kill, DNS/blackhole tests.- DR drills: full failover rehearsal monthly, with RPO/RTO measurements.- Load tests: global traffic patterns and spike simulations, failover under load.- Data consistency tests: inject conflicting writes, verify reconciliation and invariants (e.g., inventory never negative).- Observability: synthetic transactions, distributed tracing, SLO dashboards, alerting for data divergence and latency breaches.Trade-offs:- Strong global consistency increases write latency and complexity; isolate to minimal critical paths.- Active-active reduces failover time but requires conflict resolution (CRDTs) and more complex ops.This design balances availability, consistency, and latency by using strong consistency only where necessary, active-active/app-region patterns for resilience, and rigorous testing/automation to validate 99.99% uptime and single-region failure survivability.
MediumTechnical
67 practiced
Design an alert routing and escalation workflow for a multi-team organization where multiple services can fail simultaneously. Include how alerts are classified, routing rules, escalation windows, and handoff protocols between on-call teams and SREs.
Sample Answer
Requirements & constraints:- Multiple services, multiple teams, simultaneous failures possible- Need clear ownership, fast response, minimize noise, support SRE escalationDesign overview:1) Alert classification- P0 (Sev1): customer-facing outage or data loss — page primary on-call + SRE immediately- P1 (Sev2): degraded major functionality — page primary on-call, notify SRE if unresolved > 15m- P2 (Sev3): non-critical regressions/observability alerts — create ticket, notify on-call via low-priority channel- P3: informational2) Routing rules- Primary routing by service ownership metadata (service -> team on-call rota)- If service has multiple components, tag alerts with component and region; use alertmanager-style routing trees- Deduplicate/group alerts by fingerprint, correlate via traces/logs to form single incident when possible- Throttle burst: if a single team receives >N concurrent P1/P0s, trigger surge policy (auto-assign SRE pool)3) Escalation windows- P0: immediate page; if not acknowledged in 1 min escalate to next on-call and SRE lead; if not resolved in 15 min, declare incident, add exec channel- P1: acknowledge within 5 min; escalate to team lead at 15 min, SRE after 30 min- P2: acknowledge within 4 hours4) Handoff protocols- Acknowledgement required in pager system; handoff only via formal “takeover” in incident tool with: - Current incident summary, hypothesis, actions taken, next steps, links to runbooks/logs, people involved - If on-call transfers to SRE: SRE must confirm takeover in tool and optionally join call - Use 15-min synchronous overlap for critical handoffs- Post-incident: blameless postmortem owner assigned within 24h; action items tracked and linked to alert rule updatesOperational details & tooling- Use Alertmanager/Opsgenie/PagerDuty + incident timeline (StatusPage, Jira)- Maintain per-service runbooks, SLAs for acknowledgement/resolution, and automated playbooks for common failures- KPIs: MTTA, MTTR, alert noise (alerts per service per week), percent of alerts with runbookWhy this works:- Clear severity & ownership minimizes confusion- Escalation windows balance speed with on-call fatigue- Deduplication and surge policy handle simultaneous failures- Formal handoffs ensure continuity and post-incident learning.
Unlock Full Question Bank
Get access to hundreds of Reliability, Observability, and Incident Response interview questions and detailed answers.