Exercise 2: Storage Throttling vs. Outright Storage Failure — Possible Solution ==================================================================== STORAGE THROTTLING: What it looks like in metrics: increased LATENCY that correlates specifically with high disk I/O metrics -- per the chapter, "increased latency correlating with high disk I/O metrics, not CPU." The volume is still functioning and still serving requests, just more slowly than expected, because the workload has exceeded the volume's configured IOPS/throughput limit (Ch.4's storage-tier material). There's no outright error being returned -- everything technically still works, just noticeably degraded. The correct fix: resize the volume to a larger size (which typically raises its IOPS/throughput ceiling) or move to a higher-performance storage tier -- per the chapter, explicitly NOT debugging application code, since the application logic itself isn't the problem. OUTRIGHT STORAGE FAILURE: What it looks like in metrics: actual ERRORS being returned when attempting to read or write -- failed I/O operations, not just slow ones. This is a fundamentally different signal from elevated latency: requests aren't succeeding-but-slow, they're actively failing. The correct fix: this requires actual failure remediation -- depending on the cause, this could mean restoring from a backup/snapshot, failing over to a replica, or engaging the provider if the underlying hardware itself has failed -- none of which resizing a volume would address, because resizing only affects PERFORMANCE limits, not an actual failure of the storage medium itself. Why the fix differs between the two: Throttling is a CAPACITY problem -- the workload is asking for more throughput than the volume is configured to provide, and the fix is giving it more capacity. Outright failure is an AVAILABILITY/ INTEGRITY problem -- the volume (or the specific I/O operation) isn't working at all, and no amount of additional capacity fixes something that's actually broken. Treating a throttling symptom with failure-recovery steps (like restoring from a backup) would be unnecessary and disruptive; treating an actual failure by just resizing the volume wouldn't fix anything, since the volume was never under-provisioned in that case -- it's the wrong category of fix for either scenario applied to the other. WHY THIS WORKS AS AN ANSWER ------------------------------ This distinguishes the two failure modes by their OBSERVABLE SIGNATURE (degraded-but-working vs. actively failing) and connects each to the chapter's own stated fix, explaining specifically why a capacity-based fix (resizing) only makes sense for a capacity-based problem (throttling), not for a genuine failure.