Monitoring, logs, and alerts

You have drawn the food-delivery design: the customer app calls an order API behind a load balancer, the API reads menus through a cache, writes orders to a database, and puts an order-placed message on a queue that a dispatch worker reads to assign a courier. Then the interviewer asks, "How would you know this is broken?"

Monitoring is the answer to that question. It is the set of signals a running system records about itself, plus the rules that turn those signals into one decision: does a human need to act right now?

This usually comes up as a two-to-five-minute segment at the end of a product or infrastructure round, and its real weight is light. A crisp answer tied to your requirements beats a list of tools, and spending ten minutes on dashboards is a negative signal. Mid-level candidates are expected to name the right signals and alert on error rate and slow requests. Senior candidates are expected to turn a requirement into a measured target and to page only when users are hurt.

This tutorial covers what to record, what to measure on each hop of the path you drew, how a requirement becomes a target, and which breaches wake someone up. The chapters follow the order in which each decision depends on the one before it. How the signals are stored and shipped is not covered here.