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.
MediumSystem Design
53 practiced
Design a canary deployment strategy for a Kubernetes-hosted stateless microservice handling 1000 RPS. Specify how you'd shift traffic over time, what health metrics and thresholds gate promotion or rollback (both system and user-facing), how to automate the gates in CI/CD, and how to handle database migrations or schema changes safely during a canary.
Sample Answer
Requirements:- Stateless microservice on Kubernetes, ~1000 RPS steady; availability target 99.95%; safe automated canary with quick rollback; minimal user impact.High-level strategy:- Use incremental traffic shifting (e.g., Istio/Ingress + weighted routing or Service Mesh / External Load Balancer) + automated gates in CI/CD (ArgoCD/Flux + Argo Rollouts or Flagger).Traffic shift plan (example timeline):- 0% → 5% for 5 minutes- 5% → 20% for 10 minutes- 20% → 50% for 15 minutes- 50% → 100% for 10 minutesAdjust windows by risk/traffic patterns; use randomized request sampling to avoid burst bias.System and user-facing health metrics + thresholds (gate conditions):System metrics (auto-evaluated):- Error rate (5xx): fail if > 0.5% absolute increase over baseline or > 1% absolute.- Latency p95/p99: fail if p95 increases >30% or absolute > 2x SLO (e.g., >500ms).- Saturation: CPU or memory >85% on canary pods.- Pod restarts/crashloop: any restart during window triggers rollback.User-facing metrics:- Successful requests per second vs baseline: drop >5% → pause/rollback.- Business metrics (if available): checkout completion/dropoff increase >2% → rollback.Automating gates in CI/CD:- Implement Argo Rollouts or Flagger linked to Prometheus/Grafana and synthetic tests.- Define Rollout strategy: Canary steps with hooks; each step waits for Prometheus alert query to return “OK” for a duration (e.g., 2 evaluation windows).- Add synthetic canary tests (Selenium/HTTP checks) for key user flows; integrate results into gating.- Failures trigger automated rollback to previous stable revision and create incident/alert to paging system.Database migrations during canary (safe patterns):- Prefer backward-compatible migrations: additive schema changes (new columns, tables, indices) with default/nulls and feature flags.- Two-phase deploy: 1) Deploy DB migration that is backward compatible (no column drops, no incompatible type changes). 2) Deploy canary service that reads/writes safely (use feature flag to enable new behavior gradually). 3) Once canary stable and all traffic shifted, run cleanup migrations (dropping deprecated columns) in maintenance window.- For destructive changes, use blue/green or trunk-based feature flags; ensure migration is applied before enabling dependent code path.- Use DB row/connection throttling and online migration tools (pt-online-schema-change, gh-ost, or RDS-safe operations) and monitor migration lag/locks.Operational runbook:- Alert thresholds produce automated rollback; page on critical failures.- Post-mortem and incremental tuning of thresholds after incidents.- Canary must run during representative traffic; if not possible, use traffic replay.Trade-offs:- Faster shifts reduce exposure but increase risk; longer windows increase confidence but slow rollout.- Synthetic tests reduce false positives but can miss real-user edge cases—include both.This plan balances automation, safety, and speed for safe Kubernetes canaries at 1000 RPS.
EasyTechnical
49 practiced
What is a correlation ID and why is it important in distributed systems? Describe how you would implement correlation ID propagation across HTTP, gRPC and message-queue boundaries in a polyglot environment, how you would surface the ID in logs and traces, and how you would handle legacy services that do not forward headers.
Sample Answer
A correlation ID is a unique identifier (usually a UUID or trace-id) attached to a request flow so all components handling that request can be linked. It's critical in distributed systems for debugging, root-cause analysis, tracing latency across services, and grouping logs/events for one user transaction.Implementation approach (polyglot):- Naming: standardize header key, e.g. X-Correlation-ID or traceparent/trace-id when interoperating with W3C Trace Context.- Generation: edge gateway / API gateway creates an ID if absent. Use a stable format (UUIDv4 or W3C trace id).- HTTP: middleware in each service (filter/interceptor) reads header, if missing generates one, stores it in request context, and forwards header on outbound HTTP calls.- gRPC: use metadata interceptors to read/write the same header into metadata for unary and streaming calls.- Message queues (Kafka/RabbitMQ/SQS): attach ID to message headers/attributes when producing; consumer middleware reads header and injects into processing context and any downstream calls.- Polyglot: implement small, language-specific middleware libraries (or use OpenTelemetry auto-instrumentation) so all stacks behave consistently.Surfacing in logs and traces:- Logs: inject correlation ID into structured logs via per-thread/request context (MDC/logging context) so every log line includes the ID. Ensure logging format (JSON) includes the field for easy querying.- Tracing: correlate correlation ID with trace-id/span-id in tracing system. Prefer W3C Trace Context and OpenTelemetry so traces and logs link automatically.- Observability: index correlation ID as a searchable field in log aggregator (ELK/Datadog/CloudWatch) and include it in alert messages and incident playbooks.Handling legacy services that don't forward headers:- Edge or sidecar: use an API gateway, ingress, or service mesh (Envoy sidecar) to inject and persist correlation IDs. The mesh can add headers for outbound and read responses to map flows.- Message bus enrichment: have producer write correlation ID into message payload if headers aren't supported, and consumers extract it.- Proxy-based logging: capture request/response at ingress/egress to infer mapping and stitch traces centrally.- Fallback: when a downstream doesn't return a header, generate a new child ID and log mapping at the caller (parentID -> childID) so flows remain traceable.Best practices:- Use W3C trace context when possible to interoperate with tracing systems.- Keep IDs short, non-sensitive, and validate incoming IDs to avoid injection attacks.- Ensure middleware is tested and documented so all teams adopt consistent propagation.
MediumTechnical
69 practiced
Compare blackbox (synthetic) and whitebox (application-internal) monitoring. Propose a synthetic monitoring strategy for a globally distributed system to detect regional outages and degraded user experience: where to place probes, what user journeys to exercise, probe frequency, and which metrics to track to detect regional degradation quickly.
Sample Answer
Blackbox (synthetic) vs Whitebox (application‑internal)- Blackbox: external probes that emulate user interactions from outside the system (HTTP requests, UI flows). Pros: measures end‑to‑end user experience, catches network/CDN/edge issues, independent of instrumentation. Cons: limited visibility into internal root causes, can generate noise if over‑probed.- Whitebox: internal telemetry (application metrics, traces, logs). Pros: rich signals for root cause, fine‑grained latency/error breakdowns. Cons: may miss problems affecting external reachability (DNS, ISP, CDN) or degraded third‑party experience.Synthetic monitoring strategy for a global system1) Probe placement- Deploy probes in multiple regions/locations covering major user bases and backbone diversity: cloud regions (AWS/GCP/Azure) + major public ISPs/PoPs (Edge locations). Combine active cloud probes with real‑user monitoring (RUM) sampled from client regions.- At minimum: one probe per major region (NA, EU, APAC, LATAM, MEA) plus 3–5 additional probes in high‑risk network corridors (e.g., coastal vs inland, major CDNs).2) User journeys to exercise- Critical paths with high business impact and varied backend interactions: - Landing page load (first‑byte, full load) - Auth/login flow (token exchange) - Search/query and paginated results - Checkout/payment submission (if e‑commerce) - API calls used by mobile apps (simple read and write)- Include static asset fetches (CDN), SSL handshake, and DNS resolution checks.3) Probe frequency- Balance detection speed and cost: - High‑priority journeys (login, checkout): 30–60s cadence. - Medium (search, core API): 1–2 minutes. - Low (deep pages, periodic health): 5–15 minutes.- Use staggered probe schedules across locations to avoid synchronized load spikes.- Adaptive cadence: increase frequency automatically on anomaly detection.4) Metrics to track (per probe + aggregated)- Availability: HTTP status codes, success/failure rates (per journey, per region).- Latency: DNS lookup, TCP connect, TLS handshake, TTFB, content download, overall end‑to‑end time.- Throughput/error details: payload sizes, request/response times, error types (4xx/5xx), backend error rates.- Dependency health: CDN cache hit ratio, upstream API latency, DB/GW response time (if measurable).- Network path signals: traceroute/hop latency and packet loss snapshots periodically.- SLO/Alerting metrics: rate of failing probes crossing threshold (e.g., >1% failures or p99 latency > target) within a rolling window (3–5 mins).Detection & Alerting- Regional degradation rule: if N out of M probes in a region show failed availability or p95/p99 latency breach within a sliding 3–5 minute window, alert as regional outage.- Correlate with whitebox signals (error budgets, increased internal 5xx, traces) automatically to speed triage.- Provide enriched alert payload: failing probe list, latency breakdown, traceroute, recent deploys, and traffic shifts.OutcomeThis hybrid approach detects reachability and UX regressions quickly (sub‑minute for critical flows), isolates regional network/CDN issues via geographic probe diversity, and accelerates RCA by correlating with whitebox telemetry.
HardTechnical
63 practiced
An incident analysis shows repeated client retries caused cascading overload and resulted in duplicate records in a downstream system. Analyze likely root causes and propose architectural and operational mitigations: idempotency tokens, deduplication windows, transactional outbox pattern, backpressure and circuit breakers. Explain trade-offs for each mitigation.
Sample Answer
Root causes (likely)- Unbounded client retry behavior (no backoff/jitter) causing request storm when downstream latency/partial failures occur.- Lack of idempotency or deduplication in the request path so retries create duplicate side-effects.- Synchronous coupling: upstream waits for downstream and retries; no buffering/outbox.- No backpressure/circuit breakers so overload propagates through services.- Insufficient observability to detect retry storms and duplicate writes early.Mitigations and trade-offs1) Idempotency tokens- What: Require clients to send a unique idempotency key for operations; backend stores key → resulting outcome.- Benefit: Prevents duplicate side-effects even with retries.- Trade-offs: Storage & retention policy (memory leak if keys never expired), key collision/security, complexity when operations are multi-step/long-running (need to correlate across services).2) Deduplication windows- What: Apply time-windowed dedupe (e.g., keep hash of recent requests/events for X minutes).- Benefit: Simpler than full idempotency; works for eventual consistency flows.- Trade-offs: Choosing window length balances false positives vs missed duplicates; requires storage and coordination for distributed systems.3) Transactional Outbox pattern- What: Write domain event + DB change in same transaction to an outbox table; a reliable delivery process publishes events to downstream.- Benefit: Guarantees at-least-once production without distributed transactions; decouples downstream, reduces retries causing cascading overload.- Trade-offs: Additional complexity (outbox poller, schema), needs at-least-once consumers (so dedupe still needed), operational overhead.4) Backpressure and circuit breakers- What: Rate-limit incoming traffic, shed load, and open circuit when downstream is unhealthy; propagate capacity signals.- Benefit: Prevents cascading failures, reduces overload, buys time for recovery.- Trade-offs: Risk of increased client errors/latency; must tune thresholds to avoid premature or late tripping; requires client retry policy awareness (exponential backoff + jitter).Operational controls- Enforce client retry policies (max attempts, exponential backoff, jitter) via SDKs/gateways.- Add metrics/alerts: retry rate, idempotency hit-rate, duplicate write count, downstream latency/error surge.- Chaos testing and SLIs/SLOs for availability and duplicate rate; regular postmortems.Recommendation (SRE priority)1. Stop the bleed: implement circuit breakers + rate-limiting at edge and enforce client retry policies.2. Long-term: add idempotency tokens for critical write paths and transactional outbox for reliable decoupling.3. Complement with dedupe windows and monitoring to catch residual duplicates.
MediumTechnical
68 practiced
Describe how you'd implement an automated enforcement policy for error budgets across teams: when burn rate exceeds thresholds, restrict risky rollouts and throttle non-essential background jobs. Explain how you would surface budget consumption in dashboards, who owns approval for overrides, and how enforcement integrates with CI/CD or feature-flag tooling.
Sample Answer
Situation: As the SRE responsible for multiple platform services, we needed an automated way to protect SLOs when teams consumed their error budgets too quickly while still allowing essential work to proceed.Task: Build an enforcement policy that (1) detects excessive burn rate, (2) automatically constrains risky activities (canaries/large rollouts, non-essential background jobs), (3) makes consumption visible, and (4) defines clear override ownership and auditability.Action:- Detection & thresholds: Implement burn-rate evaluation in our monitoring stack (Prometheus recording rules + alertmanager or Datadog monitors). Define multi-tier thresholds (warning at 1.5x, enforce at 3x burn rate over a rolling window).- Enforcement mechanisms: - CI/CD gates: Integrate a “reliability-check” step in pipelines (Jenkins/GitHub Actions/ArgoCD) that queries a central policy service. If enforce threshold hit, pipeline blocks non-critical deployments or downgrades rollout strategy to 0%/rollback for new releases. Use feature-flag SDKs (e.g., LaunchDarkly/Flagsmith) to programmatically prevent new flag exposures. - Orchestration controls: For background jobs, automation toggles labels/annotations that a controller watches (Kubernetes operator or scheduler) to scale down or suspend CronJobs / batch jobs marked non-essential.- Visibility: Central dashboard in Grafana showing per-service SLO, current error budget remaining, burn-rate sparkline, and projected exhaustion time. Add a team-level widget and a global “at-risk” leaderboard. Dashboards link to runbooks and the last enforcement action.- Ownership & overrides: Define policy: primary ownership by the service owner (team SRE/Dev lead). Overrides require a two-step approval: (1) emergency approval by on-call SRE, (2) written sign-off in our ticketing system (Jira) by the service owner. All overrides go through a small “reliability council” (SRE manager + product IO + service lead) for post-hoc review if beyond defined windows. Every override is logged with timestamp, approver, reason, and automatic expiration.- Integration & audit: Provide a policy-service REST API and webhook that CI/CD and feature-flag platforms call. Enforcement decisions are idempotent and logged to an immutable audit store (Elasticsearch / Cloud Audit Logs). Include automated notifications (Slack) when enforcement triggers, including links to dashboard and remediation steps.- Safeguards & testing: Start with “dry-run” mode that only alerts and records what would have been blocked. Run chaos tests and game days to validate behavior. Maintain playbooks to restart operations after recovery.Result: This approach gives teams immediate protection when error budgets are threatened, clear visibility, accountable override paths, and tight integration into CI/CD and feature-flag tooling—reducing incidents caused by risky rollouts and noisy background work while preserving necessary agility. Learned to iterate thresholds per-service and keep human-in-the-loop for high-risk decisions.
Unlock Full Question Bank
Get access to hundreds of Reliability, Observability, and Incident Response interview questions and detailed answers.