Exercise 2: Mitigation vs. Fix in the Capstone's Own Chain — Possible Solution
====================================================================

The immediate mitigation, per Step 7: increasing the database
connection pool size and restarting affected instances to clear stuck
connections. This restores checkout to working order QUICKLY, ending
the customer-visible impact of the incident.

The long-term fix, per Step 6's actual root cause: adding a genuine
load-testing step to the deployment PROCESS, so that a future
deployment can't again silently ship a configuration change (like a
too-small connection pool default) that only breaks under traffic
levels nobody actually tested against before release.

Why a postmortem needs BOTH, not just the mitigation:

The mitigation fixes the SYMPTOM that was causing customer impact
RIGHT NOW -- but it does nothing to prevent the underlying gap (no
load-testing before deployment) from causing an equivalent problem the
NEXT time a similar change ships. Per Chapter 5's own warn-box,
directly echoed in this chapter: "stopping at the mitigation alone...
leaves the underlying gap ready to cause the same failure again."

If the postmortem only documented "we increased the pool size and
restarted instances, incident resolved," nothing about the actual
process gap (missing load testing) would ever get formally tracked or
assigned to anyone to fix -- the exact same category of failure
(an under-tested deployment silently introducing a limit that only
breaks under real load) remains just as likely to happen again with
some other configuration value in some future deployment. The
postmortem's action items specifically include "add load-testing to
the deployment pipeline" as its own tracked item with an owner --
precisely because the mitigation alone doesn't address it, and per
Chapter 6's own material, "a postmortem without action items is just a
story, not a learning process."

WHY THIS WORKS AS AN ANSWER
------------------------------
This distinguishes the two by WHAT EACH ONE ACTUALLY PREVENTS -- the
mitigation prevents continued impact from THIS incident, the fix
prevents recurrence of the underlying CLASS of problem -- and connects
this directly to the chapter's own warn-box logic (from Chapter 5)
about why stopping at symptom-level fixes guarantees recurrence.