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
68 practiced
Define idempotency in the context of retries. Provide two examples of operations that are idempotent and two that are not. Describe one pragmatic approach to make a non-idempotent operation safely retryable.
Sample Answer
Idempotency for retries means performing the same operation multiple times with the same input has the same effect and observable result as doing it once. This lets clients safely retry without causing duplicate side effects.Idempotent examples:- HTTP GET fetching a resource (safe, read-only).- PUT uploading a file at a fixed path (replacing same content).Non-idempotent examples:- POST that creates a new order with a new ID each call.- Incrementing an account balance (adds on each call).Pragmatic approach to make a non-idempotent operation safely retryable:Use an idempotency key provided by the client (or generated once) and store request outcomes server-side. On first request, process and persist result keyed by (client-id, idempotency-key). Subsequent retries with the same key return the recorded result without reapplying side effects. Implement TTL and garbage collection for keys, transactional writes to avoid races, and handle concurrent first requests with conditional inserts or optimistic locking.
HardSystem Design
65 practiced
Prepare a capacity planning proposal for an e-commerce service expecting a 3x traffic spike during an upcoming sale. Include autoscaling policies, headroom calculations for CPU/memory, database sizing and read replica plans, cache strategies, and a load-testing plan to validate the design.
Sample Answer
Requirements & assumptions:- 3x peak traffic for a 24–48 hour sale; baseline 1,000 RPS peak → target 3,000 RPS.- SLA: 99.95% availability, p95 latency < 300ms.- Typical request mix: 60% read product/detail, 20% cart/checkout (write-heavy), 20% static assets.High-level approach:- Right-size compute + autoscaling with headroom- Scale DB with primary for writes + read replicas for reads- Aggressive caching for product pages & CDN for static assets- Validate with staged load tests (soak + spike)Autoscaling policies (application servers):- Metric: target CPU 50% and p95 latency threshold 250ms.- Min instances = baseline_p99 * 1.2; Max = 6x baseline to handle burst.- Scale-out: add N instances if CPU > 50% for 60s OR request_queue_length > X; step scale by 25% of current or min 2 instances.- Scale-in: remove if CPU < 30% for 300s, cooldown 5m.Headroom calculation (example):- Measured: one instance handles 100 RPS at 50% CPU and 1GB mem usage.- Need 3,000 RPS → 30 instances at 50% CPU. Add 20% headroom → 36 instances.Database sizing & replicas:- Write capacity: primary provisioned for peak write QPS = baseline_writes *3 + 30% buffer; use vertical scale (cpu/memory/IOPS) to sustain write latency < 50ms.- Read scaling: add read replicas to offload reads. If reads are 60% of 3,000 RPS = 1,800 RPS and one replica handles 300 RPS, need 6 replicas + 1 spare (7).- Use semi-sync replication to avoid data loss; promoteable replica for failover.- Partition hot tables (checkout, orders) and use write-optimized shard for checkout (if necessary).Cache strategy:- CDN (Cloudfront/Cloudflare) for all static assets and cacheable product pages with TTLs (5–15 min) and cache-busting for updates.- In-memory cache (Redis/Memcached) for session, cart, product detail; provision cluster for peak RPS: required ops = read+write ops per request * RPS. Add 30% headroom.- Implement cache-aside for product reads and write-through/invalidate on product update or price change.Load-testing plan:1. Baseline tests: validate single instance throughput, latency curves, resource use.2. Spike test: ramp from baseline to 3x over 5 minutes, sustain 60 minutes.3. Soak test: sustain 3x for 4–6 hours to check memory leaks, DB bloat.4. Chaos tests: kill instances, add latency, fail read replica, CDN cold-cache.Metrics to capture: RPS, p50/p95/p99 latencies, error rates, CPU/mem/disk IO, DB replication lag, cache hit ratio.Validation criteria:- p95 latency < SLA, error rate < 0.1%, replication lag < 500ms, cache hit ratio > 80%.Trade-offs:- Aggressive caching reduces DB load but increases stale-data complexity.- More read replicas reduce read latency but increase operational cost and replication overhead.Operational notes:- Pre-warm caches and CDN before sale; perform a dry-run spike 48 hours prior.- Use autoscale scheduled policies to pre-scale 30–50% before sale window start to avoid cold-start latency.- Monitor with dashboards and alert thresholds, and have runbook for manual scale or DB promotion.
MediumTechnical
48 practiced
A team is launching a new user-facing feature. How would you choose initial SLO targets for reliability of this feature and design experiments or telemetry to refine those targets over the first quarter after launch?
Sample Answer
Situation: A new user-facing feature is about to launch and we need realistic, business-aligned reliability targets.Approach (how I’d choose initial SLOs)- Clarify scope & impact: Talk to PM/UX to determine critical user journeys the feature enables (checkout vs. optional recommendation). Map severity: critical = blocks task, important = degrades UX, nice-to-have = non-blocking.- Pick SLO types: availability (successful completion rate), latency (p50/p95 for key API or UI response), and error-rate (5xx or business failures).- Set initial targets using risk + historical baselines: if backend services exist, use their historical 30–90 day metrics as a starting point. If none, be conservative: for critical flows start at 99.9% success; for non-critical flows 99.0–99.5%. Document rationale and acceptable error budget.Design telemetry & experiments to refine over the quarter- Instrumentation: - End-to-end synthetic tests for core journeys every minute. - Real-user monitoring (RUM) to capture client-side latency and failures. - Server-side traces, per-endpoint latency histograms, error codes, and business-logic failures tagged by user cohort and release. - Capture user impact metrics (conversion, completion rate, drop-offs) tied to reliability signals.- Rollout strategy: - Canary + progressive rollout (1% → 5% → 25% → 100%) with automated gates that check SLOs, error budget burn, and user-impact metrics. - Feature flag to quickly rollback.- Experiments & analysis: - Define hypotheses (e.g., “p95 latency > 1s reduces conversion by 3%”). - Run A/B or cohort comparisons during rollout to quantify user impact vs. reliability. - Use burn-rate and statistical tests (95% confidence) to decide if target is too strict/loose.- Iteration cadence: - Weekly dashboard reviews + alerts for urgent regressions. - At 30/60/90 days, re-evaluate SLOs: compare actual distribution to targets, correlate reliability incidents with user-impact metrics, and adjust SLOs and error budgets with stakeholders.- Governance: - Document SLOs, owner, and error budget policy. Tie SLO misses to postmortem actions and prioritization rules.Result: This approach yields defensible initial SLOs, measurable experiments to prove user impact, and a feedback loop to converge on stable, business-aligned targets within the first quarter.
HardSystem Design
54 practiced
Architect a multi-region service that must provide 99.99% availability for reads and acceptable write latency across regions. Discuss replication strategies, consistency models, automatic failover processes, SLO definitions, and a runbook for region failover including test plans.
Sample Answer
Requirements & constraints:- Reads: 99.99% availability (four 9s) globally.- Writes: acceptable cross-region latency (e.g., <200–500ms for geo-writes).- Multi-region active-read capability, automated failover, durable storage, predictable consistency trade-offs.- RTO/RPO targets: RTO < 5 min, RPO < 1s (example — align with business).High-level architecture:- Primary region for writes with per-region read replicas; optional multi-master for local-writes using conflict resolution.- Global load balancer (GSLB) + health checks directs reads to nearest replica; writes routed to primary or to local write gateway (if multi-master).- Storage: strongly-consistent transactional store in primary (e.g., leader-based Raft cluster) + async replication to other regions; optional CRDT/event-sourced layer for local-writes.Replication strategies & consistency:- Option A (recommended): Single-writer leader + async replication with tailing replicas. Provides strong consistency for reads-in-primary and eventual consistency elsewhere. Use read-your-writes via session tokens or read affinity.- Option B: Multi-master with causal consistency and CRDTs for commutative ops — lower write latency but more complex conflict resolution.- Use hybrid: sync quorum writes for critical objects (write to majority of regions synchronously) and async for less critical data.Automatic failover:- Health monitoring at node, cluster, region level. Automated leader election via consensus (e.g., Raft) inside region. Cross-region failover: pre-authorized promotion that requires health signals + quorum across control plane nodes in other regions.- GSLB with low TTL DNS + Anycast/HTTP health checks switches traffic on failover. Use phased promotion: freeze-writes in failing region, ensure replication up-to-date, promote target region leader, reconfigure writer endpoints.SLOs & metrics:- Availability: reads 99.99%; writes 99.9% (example).- Latency: p50/p95/p99 reads and writes; write p95 < 500ms.- Durability: successful replication to N regions within T secs.- Monitor: replication lag, commit index, error rates, traffic, failover time.Runbook for region failover (summary):1. Detect: automated alert triggers when > threshold failed health checks + replication lag.2. Triage: confirm region outage via control-plane sensors.3. Pause clients: route writes to readonly mode if needed.4. Promote: validate latest committed index on candidate region, promote leader (consensus-driven).5. Reconfigure: update service discovery, rotate certificates if needed, update GSLB.6. Verify: smoke tests (read/write), data integrity checks, replay missing logs.7. Rollback plan: if promotion fails, revert to previous routing and investigate.Test plans:- Automated chaos tests (Chaos Engineering): simulate region outage, network partition, delayed replication.- DR drills quarterly: full failover and failback with SLA measurement, runbook time measurements.- Load tests: measure replication lag under peak writes.- Consistency tests: verify read-your-write, stale-read windows, and conflict resolution coverage.Trade-offs:- Single-writer simpler, stronger guarantees but higher cross-region write latency; multi-master reduces latency at cost of complexity.- Synchronous cross-region quorums increase write latency but improve durability.Implementation notes:- Use durable WAL/append-only log + replication stream, idempotent replay.- Expose session stickiness to clients for read-your-writes.- Automate runbook steps with scripts/Orchestration to meet RTO/RPO.
MediumSystem Design
53 practiced
You inherit a CI/CD pipeline for a microservices platform. Describe where and how to insert canary deployments and progressive rollouts. Specify the metrics to monitor during canaries, automated rollback triggers, and how to test the canary mechanism itself in staging.
Sample Answer
Requirements & constraints:- Minimize user impact; support rapid rollback; work per-microservice independently; integrate with existing CI/CD (e.g., Jenkins/GitHub Actions + Helm/ArgoCD/Kustomize); support traffic shaping (service mesh or API gateway).Where to insert canaries:- After CI and automated tests, inside CD pipeline before full promotion to prod.- Pipeline stages: build → unit/integration tests → image push → deploy canary → observe metrics → promote or rollback → full rollout.- Use orchestrator + traffic controller: - Kubernetes + Istio/Linkerd/Envoy or API Gateway (NGINX/Traefik) to split traffic. - For serverless, use provider-native traffic weights (Lambda alias, Cloud Run traffic split).Progressive rollout strategy:- Start with small percentage (1-5%) for initial canary for ~15–30 minutes, then ramp to 10–25% (if healthy) for a longer period, then 50%/100% as final promotes.- Use automated ramps (e.g., Flagger with Istio, Argo Rollouts) or scripts that adjust weights.Metrics to monitor during canaries:- Health & availability: error rate (4xx/5xx), HTTP success ratio- Latency: P95/P99 response times, request queue time- Resource metrics: CPU, memory, threadpool/executor saturation, GC pauses- Business/functional: request throughput, conversion rates, key business transactions- Logs & traces: increased exceptions, new stack traces, SLO/SLA alerts- Dependency metrics: DB errors, downstream timeoutsAutomated rollback triggers (examples):- Error rate increase by absolute >1% or relative >200% vs baseline for 5m- P95 latency increase absolute >200ms or relative >150% for 5m- Any SLO breach or critical alert from APM/monitoring- Resource saturation >85% leading to pod restarts/throttling- New uncaught exceptions frequency spike (thresholded)- Circuit-breaker tripped or downstream error amplificationImplementation details:- Use Prometheus + Grafana + Alertmanager, plus APM (Datadog/NewRelic/Jaeger).- Implement thresholds as part of rollout controller (Flagger/Argo Rollouts) to automatically rollback and notify on-call.- Store baseline by scraping production metrics of current stable version for comparison.Testing canary mechanism in staging:- Create a staging cluster that mirrors prod traffic patterns and dependencies (use synthetic traffic via k6/Locust).- Deploy canary pipeline against staging and run: - Happy path: follow normal ramp, verify promotion. - Failure injection: introduce faults (latency, 5xx, DB failure) using Chaos Toolkit/Gremlin or Istio fault injection and assert automated rollback triggers. - Load tests to validate metrics and resource thresholds.- Run end-to-end tests and synthetic business transactions during each stage.Operational practices:- Keep rollout configuration in Git (GitOps) and parameterize percentages/timing.- Require canary windows and automatic/manual gates per service criticality.- Add observability dashboards and incident runbooks linked to pipeline events.- Periodically review thresholds and update baselines as traffic patterns evolve.This approach gives safe, automated progressive rollouts with clear metrics-driven rollback and repeatable staging tests.
Unlock Full Question Bank
Get access to hundreds of Reliability, Observability, and Incident Response interview questions and detailed answers.