Monitoring & Observability

Every system you design will fail at some point. The difference between a 5-minute outage and a 5-hour one is how quickly you detect the problem and understand its cause. Monitoring and observability are how you do that. In interviews, mentioning observability at the right moment signals operational maturity. Something like "and we'd add metrics here to track latency percentiles" does the work.

Monitoring and observability get used as synonyms, and the difference matters once a system has more than a handful of services. Monitoring is the questions you decided to ask in advance: the dashboards someone built, the thresholds someone picked. Observability is whether the telemetry you already collect can answer a question nobody thought of, mid-incident, without shipping code to find out.

That difference has teeth. Most serious outages have a cause that was never on a dashboard: one bad host in a fleet of two hundred, or one customer sending payloads ten times the normal size. Incidents reduce to the same question every time. Is this everything, or one region, one deploy, one tenant? Telemetry you cannot slice that way leaves you guessing.