Frameworks Quiz

Request Path — Typical Flow:

1. User — Request originates from the client.
2. DNS / GSLB — DNS resolves the hostname; GSLB routes traffic to the nearest healthy region.
3. CDN / LB — CDN serves cached content at the edge; load balancer distributes traffic across backend instances.
4. API gateway / ingress — TLS is typically terminated here; handles auth, rate limiting, and routing to services.
5. Service — Application logic processes the request.
6. Cache / DB / dependencies — Service reads from cache (hit) or falls through to the database or downstream dependencies (miss).

Common user-facing SLIs:

• Availability — % of requests returning a successful response
• Latency — p95 or p99 response time
• Freshness — % of responses containing data within an acceptable age
• Error rate — % of requests resulting in an error
• Durability — data loss rate (stateful systems only)

CPU utilization and Disk I/O are infrastructure metrics — they are useful for debugging and capacity planning but should not be primary SLIs because they don’t directly reflect what users experience.

Incident Response Framework:

1. Confirm — Verify the issue is real, current, and user-impacting.
2. Scope — Determine blast radius: who, what, where, since when.
3. Correlate — Identify recent changes that could explain the issue.
4. Stabilize — Pause risky changes and stop the incident from expanding.
5. Locate — Narrow the fault domain using golden signals and dependency tracing.
6. Mitigate — Take the fastest safe action to reduce user impact.
7. Root Cause — Identify both the trigger and the missing safeguard.
8. Recover — Confirm the system is truly healthy, not just quieter.
9. Prevent — Add fixes, guardrails, and learnings to avoid recurrence.

4 Golden Signals (LETS):

1. Latency — How long requests take (split p50 / p95 / p99)
2. Errors — Rate of failed requests
3. Traffic — Request volume (RPS or events/sec)
4. Saturation — Resource pressure (CPU, memory, queue depth)

Break each signal down by dimensions — region, endpoint, dependency, customer segment — so that when an SLO fires, you can isolate where the problem is, not just that something is wrong.

SRE System Design Framework:

1. User Experience — What matters most to users?
2. SLIs / SLOs — How do we measure success?
3. Request Path — How does traffic flow end to end?
4. Core Components — What does each layer do and why?
5. HA Design — How do we survive instance, AZ, and region failures?
6. Failure Modes — What breaks, what is the blast radius, how do we contain it?
7. Cascading Failures — Timeouts, retries, circuit breakers, backpressure.
8. Scaling — How does the system grow safely?
9. Observability — Metrics, logs, traces, alerting.
10. Operations — Deploy, rollback, runbooks, game days.

Observability & Alerting Design Framework:

1. User Experience — Anchor everything to what users actually feel.
2. SLIs — Pick 2–4 measurable indicators of user experience.
3. SLOs — Set reliability targets and define error budgets.
4. Signals — Golden Signals + dimensions (region, endpoint, path).
5. Instrumentation — Metrics (aggregate), logs (debug), traces (latency).
6. Alerting — SLO-based burn-rate alerts — page only on user impact.
7. Failure Modes — Identify likely failure patterns and verify detectability.
8. Scaling & Cost — Control cardinality, sample traces, tier storage.