Stale view results when using stale=ok in CouchDB

Goal: Choose a stale mode for CouchDB view queries that balances read latency with acceptable data freshness under fluctuating write loads.

Constraint: The application does not have a built‑in policy to automatically switch between stale=ok, stale=update_after, and stale=false, and the impact of each mode on result staleness is not quantified for the current workload pattern.

Uncertainty: Without monitoring, it is unclear how often stale=ok will return noticeably outdated rows or how delayed the asynchronous update triggered by stale=update_after becomes during peak writes.

Questions: What measurable indicators (e.g., update_seq lag, active indexer tasks) should trigger a switch from stale=ok to a fresher mode? How can latency versus staleness trade‑offs be expressed as a configurable threshold? Is there a reliable way to automate stale mode selection based on real‑time view lag?