Skip to lesson
Exit
Edge, Security & Multi-Region Deployment1 / 2

2 min lesson

Observability across regions

Explain your answer to "Why does mature on-call alert on the error-budget burn rate rather than on a fixed error-count threshold?" Add one concrete detail from the lesson.

Step 1 of 2

Observability across regionsyou can't debug what you can't trace

A request that crosses edge → mesh → service across regions is invisible without distributed tracing. Propagate a trace context from the edge down and correlate it with metrics and logs so one slow request tells you which hop ate the time.

  1. 1Inject a trace/request ID at the edge and carry it through every hop and every log line.
  2. 2Trace the path edge → ingress → mesh sidecar → service → datastore, with spans you can read as a waterfall.
  3. 3Tag spans by region and node so a region-localized problem stands out instead of averaging away.
  4. 4Correlate the three pillars - jump from a latency metric to the exemplar trace to the logs for that exact request.
Interview move

Tie your design back to an SLO unprompted. "This edge change protects the latency SLO; this failover plan protects the availability SLO; here's how I'd alert when either budget burns fast." Framing decisions as SLO-driven shows you optimize for what users feel and for defensible tradeoffs, which is exactly the judgment Cursor screens infra hires for.

Burn-rate alerting beats threshold alerting

Don't alert when errors cross a fixed line. Alert on error-budget burn rate: a fast burn (you'll exhaust the month's budget in an hour) pages immediately; a slow burn opens a ticket. It catches both the sudden outage and the steady erosion without drowning on-call in noise.