Exercise 2: Diagnosing "Intermittent Timeouts" From a Diagram — Possible Solution
====================================================================

The diagram: a load balancer, two web servers behind it, and a
database inside a separate dotted boundary (a private subnet, per
`cloud1-5`'s public/private subnet pattern).

Where to check first: the WEB SERVER INSTANCES (behind the load
balancer), specifically their health check status and per-instance
metrics -- and here's the reasoning, working through the architecture:

"INTERMITTENT" is the key word in the symptom description. A load
balancer distributes traffic across multiple backend instances using
health checks (`cloud1-5`) -- if ONE of the two web servers is
unhealthy, overloaded, or intermittently failing (rather than both
being down, or the load balancer itself being broken), users would
experience exactly this pattern: some requests succeed (routed to the
healthy instance) while others time out (routed to the struggling
one), rather than a total, consistent outage.

Per `cloud1-8`'s monitoring workflow, the practical first step is
checking METRICS for each web server instance around the reported time
window -- CPU, memory, or request latency spiking on one instance but
not the other would strongly point at that specific instance as the
source, before drilling into its logs for the specific error detail.

Why NOT the database first: the database sits in a private subnet
specifically to be inaccessible from outside (`cloud1-5`/`cloud1-7`'s
deliberate pattern) -- if it were failing entirely, the symptom would
more likely be a total, consistent failure across both web servers
(since both presumably depend on the same database), not an
INTERMITTENT one tied to which server happens to handle a given
request. That said, if per-instance web server metrics come back
clean, the database (or the specific connection pool exhaustion
scenario from `cloud1-7`) would be the logical next thing to check.

Why NOT the load balancer itself first: a load balancer misconfigured
badly enough to cause timeouts would typically affect requests more
uniformly (or fail outright) rather than intermittently succeeding and
failing in a pattern that tracks which backend instance happened to
receive the request.

WHY THIS WORKS AS AN ANSWER
------------------------------
This applies `cloud1-8`'s own "metrics first, narrow down where/when,
then logs" workflow directly to the diagram, and specifically uses the
word "intermittent" in the symptom as the diagnostic clue that points
toward one of two backend instances rather than a single shared
component like the load balancer or database -- exactly the kind of
symptom-to-architecture reasoning this chapter's own material on
reading diagrams is meant to build.