A municipal inspections platform is mostly asynchronous, yet reliability dashboards still alert only on HTTP 5xx from the web tier. Backlogs and poison messages grow unnoticed. Which observability improvement best fits async reliability?
Select an answer to reveal the explanation.
Short Explanation
Async systems fail quietly—the website can smile while the work pile rots. Watch queue depth, message age, and DLQs like you watch 5xx, or inspections will stall without a red banner.
Full Explanation
A municipal inspections platform that is mostly asynchronous yet alerts only on HTTP 5xx from the web tier will miss growing backlogs and poison messages. Monitoring queue depth, age of oldest message, and DLQ rates as first-class reliability signals alongside web-tier errors fits async reliability because work can fail silently after the HTTP response succeeds. That observability improvement works when citizen-facing acknowledgements hide stalled workers and dead-letter piles. Ignoring SQS ApproximateNumberOfMessages metrics because they are not HTTP status codes fails conceptually: async health is not an HTTP code. Deleting dead-letter queues so failed messages disappear from dashboards fails by destroying evidence and retry opportunities. Paging only when EC2 CPU is idle, treating quiet hosts as healthy workers, fails when idle CPU means workers are stuck or starved of messages. Exam caveat: thresholds must distinguish healthy diurnal backlog from stuck age-of-oldest-message; alarm on age and DLQ rate, not depth alone during expected peaks. Operational check: dashboard ApproximateNumberOfMessages, ApproximateAgeOfOldestMessage, and DLQ counts; inject a poison message in nonprod; confirm pages fire; and verify remediation clears DLQ without silent drop.