Do you mean reads of the same record (that is, identified by the same key)? Or do you mean concurrent reads of different records?
Aerospike is a multi-node, multi-core, multi-threaded system. Service threads pick up incoming operations, placing them on one of several transaction queues (often one of those is defined per-core). Those operations are then handled by transaction threads running on different cores, in parallel.
At the record level, operations are serialized if they happen concurrently. Read locks are slightly lighter than write latches. The number of operations queued up on a single record is controlled by the transaction-pending-limit config parameter, and has a default depth of 20. If that is exceeded, your client will get an exception with error code 14 (key busy). If this queue is frequently exceeded you have a “hot key” situation.
The way you handle a hot key depends on your business logic, and operational limits. You can temporarily raise the config param’s value, but it applies to the entire server node. You can change the read.replica policy to read from any of the replicas, instead of just the master, distributing the read load. You can also partition the key on the application side.