To future readers, this model will likely change a bit with Aerospike 4.2.0.
During an update, a ‘record lock’ is held for the time required to read the record from either cache or storage-engine, merge with update, and write back to an in-memory buffer. The lock doesn’t cover the time for the buffer to flush to the storage-engine.
You can speed this up significantly if you are able to use the ‘replace’ policy when a record already ‘exists’. This policy replaces the record with the bins provided by the write allowing the write to bypass the read and merge portion of the write process. This wouldn’t be an option if your writes do not contain all of the bins on the record being written to - though if your records are not large it still may be faster to read all the bins and write them all back with a replace.
Also as @pgupta has mentioned, if you are reading and updating in the same transaction, look into ‘Operate’ and the ‘replace’ policy would still be beneficial if it fit your use case.