Exercise 2: Reading Your Own Just-Written Data — Possible Solution
====================================================================

This scenario calls for a STRONGLY CONSISTENT read specifically. The
application's own correctness depends on seeing the exact write it
just made -- not an approximately-current view of the data, but the
genuinely current one.

The default option, an eventually consistent read, is routed to a
random replica node rather than the leader node that received the
write. AWS's own real, documented figure gives roughly a 1-in-3
chance of that random node not yet reflecting the write, within the
write's own short propagation window -- meaning the application could
genuinely read back stale data (missing its own just-made write) and
proceed incorrectly based on it, even though in the large majority of
real cases the window closes within milliseconds and no problem would
actually occur.

ANSWER: This scenario requires a strongly consistent read, since it
is always routed to the leader node and therefore always reflects the
most recent successful write. Using the default, eventually
consistent read here would risk a real, if usually brief, chance of
the application reading stale data and making its next decision based
on information that doesn't yet include its own prior write.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the specific real risk (reading your own
just-written data back) that strong consistency exists to guarantee,
rather than defaulting to "always use eventually consistent since it's
faster and cheaper" -- matching the chapter's own warn-box guidance
that strong consistency should be reached for only when the specific
correctness need actually justifies it, as it clearly does here.