Firestore transactions vs sharded atomic writes for a hot document under concurrency

Goal: Keep commit latency predictable for a single Firestore document targeted by many concurrent clients while preserving application invariants.

Firestore transactions use optimistic concurrency control and retry aborted commits with backoff, so tail latency appears only under contention. Atomic field transforms and sharded writes avoid read-modify-write conflicts but spread state across documents and require application-level reconciliation for reads.

Exact server-side contention latency, retry limits, and backoff schedules are not published in public documentation, and the roughly one-write-per-second guideline is not a hard quota. It is unclear which approach minimizes p99 latency under sustained concurrent writes without sacrificing consistency guarantees.

Which documented write pattern should be used for a hot document when p99 latency matters more than write volume: Firestore transactions with automatic retries, or sharded atomic writes with client-side aggregation?