Exercise 3: Why Session Consistency Fills a Real Gap DynamoDB Doesn't — Possible Solution
====================================================================

DynamoDB offers only two real consistency options: Strong (every read
reflects the latest write, for every reader, globally) or Eventual
(no ordering guarantee at all, with a real, documented chance of
returning stale data). There is no real middle option in DynamoDB's
own model -- a team wanting read-your-own-writes reliability for one
specific client is forced to choose Strong consistency, even though
that guarantee is really only needed for that one client's own reads,
not for every reader in the system.

Cosmos DB's real Session consistency level, its own default, is
specifically designed for exactly this real gap: it guarantees a
single client always sees its own prior writes immediately
(read-your-own-writes), without requiring the same full, real Strong
guarantee to be paid for and applied to every other reader in the
system globally.

ANSWER: Session consistency fits this need better because it directly
provides read-your-own-writes reliability for the specific client that
needs it, without requiring the full real cost of Strong consistency
to be applied everywhere -- a genuine middle ground DynamoDB's own
two-option model (Strong or Eventual) simply doesn't offer, forcing a
choice between paying for full global strong consistency or accepting
Eventual's own real risk of returning stale data to a client reading
its own recent write.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the specific real gap in DynamoDB's binary
choice (no read-your-own-writes-only option) and explains exactly how
Session consistency fills it, rather than simply asserting "Cosmos DB
has more options" without connecting that richness to the concrete
real need described in the scenario.