Start here. This is the direct spoken answer to practice first.
Why this question matters
Consistency is a product decision before it is a database setting. Different operations can tolerate different amounts of staleness, and the design needs to protect real invariants without making every read depend on every component.
I would classify each operation by the harm caused by stale or conflicting data. Uniqueness, authorization changes, inventory reservation, and payment state often need a strongly consistent decision at one source of truth. Search indexes, analytics, feeds, and notification counts can usually lag if the product communicates that behavior. During a failure I would prefer an explicit unavailable or pending result for a critical write over accepting an operation whose invariant cannot be checked. For tolerant reads, I would serve the last known state and record when it was produced.