Is it possible to relax the consistency guarantees of transactions? From my current understanding, writes must be durable on all replicas before the transaction is committed, thus impacting latency. Snapshot reads are available but they only relax isolation guarantees.
As far as I think, your understanding is wrong. The only thing need to be durable before committing is transaction log. Which should(If I remember correctly) be an append-only log file. Updating an append-only log file is very fast.
So for failure tolerance, we not only need to keep at least one of the three storage servers alive, but also need to keep at least one of the three transaction log servers alive.
A commit needs to be persisted to disk on multiple tlog servers (same number as replication factor) before transaction can be acknowledged. I am not sure if there is any requirement for any of the storage servers to be alive at time of transaction commit.
To amortize the cost of transaction commits, proxies batch multiple transactions happening over small durations.
If you want to improve latency at the expense of consistency, you can use CAUSAL_READ_RISKY (which makes getting a read version slightly cheaper), or avoid getting new read versions frequently by manually setting the read version for some of your transactions. You might read a stale value, but you still won’t be able to commit a transaction that read a stale value (unless you opt out of that too by messing with read conflict ranges/snapshot reads)
For acknowledging before a commit is durable on all transaction logs, you can configure a non-zero “tlog anti quorum”, but I don’t think anyone actually does this or recommends doing it because it could allow a tlog to fall behind.