Monitoring a microservices architecture means tracking a specific set of metrics across many independently running services to catch performance issues and failures before they impact users.
Key Points: • Latency and response time show how fast each service is responding, and are usually tracked as percentiles (p50, p95, p99) rather than just averages, since averages hide outliers. • Error rates reveal how often requests to a service fail, which is often more actionable than raw request counts alone. • Resource utilization — CPU, memory, disk, and network — indicates whether a service is under-provisioned or about to hit a resource ceiling. • Throughput (requests per second) helps with capacity planning and spotting unusual spikes or drops in traffic that may indicate an upstream problem. • Inter-service metrics like queue depth in a message broker or connection pool saturation reveal bottlenecks in how services communicate with each other.
Example: A dashboard tracking p99 latency and error rate per service would immediately flag if the Payment Service's p99 latency jumped from 200ms to 3 seconds after a deployment, well before the average latency metric showed any noticeable change.
Interview Tip: A concise interview answer is:
"I focus on latency percentiles rather than averages, error rates, resource utilization like CPU and memory, and throughput per service, plus inter-service signals like message queue depth. Percentile-based latency in particular tends to surface problems that averages hide, so that's usually where I look first when something feels slow."