Replicated lock acquisition currently replicates through Raft synchronously. This can impose a high latency on read committed transactions which perform a large number of SELECT FOR UPDATE operations or a large number of FK lookups.

This was discussed in the Read Committed RFC under the Row-Level Locks > Reliability and Enforcement section. That section also outlined a collection of possible optimizations that we could make to avoid this latency penalty.

The most promising of the optimizations is to pipeline this lock acquisition using the using AsyncConsensus infrastructure. This will require client-side tracking and a new protocol to validate pipelined lock acquisition. It is analogous to our existing write intent pipelining approach.

Jira issue: CRDB-35440