Exercise 1: Why "Works Sometimes, Fails Other Times" Is a Version-Skew Signature — Possible Solution
====================================================================

WHY THIS PATTERN POINTS TO VERSION SKEW
------------------------------
Per this chapter, "a rolling or blue-green deployment inevitably
passes through a window where old and new code run simultaneously,
across different server instances." During that window, two genuinely
different versions of the application are both actively serving live
traffic at the same time - not a single, consistent version.

WHY THE FAILURES ARE EFFECTIVELY RANDOM TO A USER
------------------------------
Per this chapter, "which instance answers a given request is
effectively random during the rollout, and each instance is running
one version or the other, never a blend." A user (or a service calling
another service) has no way to control or predict which specific
backend instance a load balancer routes their request to - so whether
a given request succeeds or fails depends entirely on an implementation
detail (routing) the user has no visibility into, producing exactly
the "works sometimes, fails other times" experience with no apparent
pattern from their side.

WHY "NO CODE CHANGES SINCE" MAKES SENSE TOO
------------------------------
The instability isn't caused by anything changing after the deploy
finished - it's caused by the deploy itself still being in progress,
with the instance mix shifting as the rollout proceeds. Once the
rollout completes and every instance is running the same version, the
inconsistency disappears on its own, without any further code changes
being needed.

WHY THIS WORKS AS AN ANSWER
------------------------------
It connects the symptom directly to the mechanism (simultaneous
old/new instances) the chapter describes, and explains specifically
why routing randomness makes the failures appear unpredictable from a
user's perspective despite having a fully deterministic underlying
cause.