As Matt says, CRDB gives you serializable transactions, so from a data consistency perspective transactions are completely isolated from each other. Transactions may be forced to retry though, in order to guarantee this isolation.
If you explicitly want to queue things up, which can be a a legitimate thing to do for performance considerations, you can achieve that by introducing a dummy key that all these overlapping transactions write to as the first thing they do. This will achieve queuing - each write will block until the previous txn writing to that key commits.
There’s periodic talk of supporting
select for update clauses for these purposes and/or the Postgres advisory lock functions (pg_try_advisory_lock() and friends). So far, neither of these are supported.