So there is a second level of ordering complexity - submission timestamp. This is an interesting data modeling problem. I think the following model will work:
Maintain a record for retrieving rank which has the following key:value map bin - key is list of [score, timestamp], value is userid. (Java client will work, other clients check if map key as a list is supported.)
rank_rec_0: { ...., [score, timestamp]:userid, .... }
For argument sake, lets assume all your users fit into one such record. Then user rank will be get_by_value(userid) and return value type - INDEX.
In your case, all users will not fit into one record.
If you have good assessment of rank vs user count distribution and this is a bounded problem in terms of number of users, you can break the records into multiple records.
rank_rec_0: {....}
rank_rec_1: {....}
rank_rec_2: {....}
rank_rec_3: {....}
Based on score, if a userid must be entered in rank_rec_2, then its rank will be: map_size of rank_rec_0 + map_size of rank_rec_1 + index in rank_rec_2. [Now that may be the reverse rank, but reverse can also be computed likewise]. So you will read multiple records but that should all be possible within the 100 ms window. Typical reads in Aersopike are in 1 ms order.
If such bounded, simplistic segregation of rank_rec by score is not possible, then you have to come with a more creative - self-sharding map implementation in Aerospike.
You can watch this recording: Summit '19: Key Data Modeling Techniques | Aerospike at around 32:00 minutes, Adaptive Map for a different problem is discussed. Some ideas from there can be re-purposed for this problem.
Or if you plan to be an Aerospike Enterprise Customer in the future, Aerospike’s Solution Architecture team may be able to help.