What are the four Golden Signals for service health monitoring?

WHAT THIS TESTS: Whether you understand the difference between user-visible symptoms and underlying causes after a push. The interviewer wants to see that you prioritize request-level metrics that catch regressions immediately, rather than paging on machine-level noise that may not correlate with user pain.

A GOOD ANSWER COVERS: Four signals in order of diagnostic value. First, latency: the time it takes to service a request, distinguishing between successful request latency and failed request latency because slow errors are worse than fast errors. Second, traffic: a measure of demand on the system such as HTTP requests per second or transactions per minute, which provides context for whether a spike in errors is proportional. Third, errors: the rate of requests that fail explicitly or implicitly, including HTTP 500s, protocol errors, or policy violations like returning stale data. Fourth, saturation: how full the service is relative to its capacity, such as memory utilization, thread pool occupancy, or disk IO that directly constrains request handling. A great candidate also notes that saturation is often the hardest to instrument because it requires knowing the actual capacity limit rather than just a percentage.

COMMON WRONG ANSWERS: Listing generic infrastructure metrics like CPU percentage, disk free space, or load average as the primary signals. These are useful but secondary; they describe the machine, not the user experience. Another red flag is omitting saturation entirely or treating it as identical to utilization. Saturation specifically means the resource is actively throttling work, not merely that usage is high. Confusing traffic with bandwidth or network throughput is also a miss; traffic is request demand, not bytes transferred.

LIKELY FOLLOW-UPS: How would you measure saturation for a stateless microservice versus a database? When would you alert on latency percentiles versus averages? How do you distinguish between a traffic spike caused by a legitimate launch versus a DDoS? What dashboards do you build for a canary deployment using these four signals?

ONE CONCRETE EXAMPLE: After a deployment, traffic holds steady at 10,000 requests per second but latency jumps from a p99 of 200 milliseconds to 800 milliseconds and error rate climbs from 0.1 percent to 2 percent. CPU is only at 40 percent, so an infrastructure-only alert would not fire. Checking saturation reveals the connection pool is exhausted because the new release leaks connections. The Golden Signals surface the regression in user-facing terms within minutes, while machine metrics stay green.