Exercise 1: A Database and a Backup Job, Two Different Bottlenecks — Possible Solution
====================================================================

THE TWO WORKLOAD SHAPES
------------------------------
Per this chapter, "a workload of many small, random operations (a busy
database) is IOPS-bound... a workload of a few large, sequential
transfers (a backup job copying big files) is throughput-bound."
Both involve heavy disk activity, but the shape of that activity is
fundamentally different.

WHY THE DATABASE IS IOPS-BOUND
------------------------------
Per this chapter, a busy database "can look fine on throughput while
genuinely struggling on IOPS and latency." Each individual database
operation (a row lookup, a small write) is small in terms of raw data
moved, but there are many of them happening per second - the
bottleneck is how many separate operations the disk can service, not
how much total data moves.

WHY THE BACKUP JOB IS THROUGHPUT-BOUND
------------------------------
Per this chapter, a backup job "can post huge MB/s numbers while
barely touching IOPS." Copying large files involves comparatively few,
large sequential operations - the bottleneck is how much raw data can
move per second, not how many separate operations are issued.

WHY THIS MATTERS DIAGNOSTICALLY
------------------------------
Per this chapter, "knowing which kind of workload you're looking at
changes which number actually matters." Checking throughput on an
IOPS-bound database, or checking IOPS on a throughput-bound backup job,
would miss the metric that actually reflects that workload's real
bottleneck.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains both workload shapes using the chapter's own terminology
(IOPS-bound vs. throughput-bound), gives the specific reasoning for
why each workload is bound by its particular metric, and connects this
to why picking the right metric to check matters.