Exercise 2: Why There Is No Cheaper Eventually Consistent Read on Firestore — Possible Solution
====================================================================

On DynamoDB, choosing between eventually consistent and strongly
consistent reads is a real, explicit decision the developer makes on
every request, and the eventually consistent option is genuinely
cheaper - it costs half as much as a strongly consistent read.

Firestore does not offer this choice at all. Every read on Firestore
is always strongly consistent - there is no eventually consistent
read mode to opt into, at any price. The developer will find that the
option they are looking for simply does not exist on Firestore,
because Firestore's own real design guarantees strong consistency
unconditionally rather than treating it as a configurable,
priced-differently tradeoff the way DynamoDB does.

ANSWER: The developer will find that Firestore has no eventually
consistent read option at all - every Firestore read is always
strongly consistent, with no cheaper alternative to choose, because
Firestore guarantees strong consistency as a fixed, built-in
property rather than a configurable tradeoff.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies that Firestore's real consistency model has
no per-request choice at all, unlike DynamoDB's own explicit and
differently-priced eventual/strong split, directly reusing the
chapter's own central real finding.