A professional social network runs about 3,000 microservices owned by roughly 400 teams across several data centres, with an Envoy-based service mesh. About a fifth of services have an SLO, most of them copied from a template and never revisited. On-call pages fire on CPU and on individual error spikes. During last month's messaging outage, it took 50 minutes to find who owned the failing dependency.
The interviewer asks“Design how ownership, SLOs and error budgets work across the whole estate. How does every service get an owner and a sensible SLO, how do alerts work, and what actually happens when a team burns through its budget?”
I'd make the service catalog the source of truth: every service has an owning team that's validated against the identity provider and on-call schedules, a tier, and declared dependencies, and CI refuses to deploy a service that isn't in it. Each tier comes with an SLO template whose SLIs are generated from mesh and load-balancer metrics, so 3,000 services get availability and latency SLOs without hand instrumentation, and teams only adjust targets. Alerts are generated multi-window, multi-burn-rate alerts that page on fast burns and open tickets on slow ones. A leadership-signed error-budget policy is enforced by the deploy system. I'd add dependency composition rules so tier-0 services only hard-depend on tier-0 services or have fallbacks, weekly budget reporting with attribution, and a process that finds and re-homes orphaned services.
A free account unlocks the rest of it, and saves your progress across every track.
sar Collect and replay system activity historympstat Per-CPU utilisation: find the hot corepidstat Per-process CPU, memory, disk and context switches over timesysctl Read and tune kernel parameters at runtimeulimit Show and set per-process resource limitsnumactl Control NUMA CPU and memory placementstrace Trace the system calls a process makesltrace Trace the library calls a program makes