This is not actually a noob question. This is wonderful question which I think lot of e-commerce people will be trying to solve. Let me take my dig at addressing the problem.
I dont think this will be solved by any data store with very less copies of the data. typically nosql databases have 2 or 3 copies. the reads can be scaled a bit by doing round-robin between copies of the record. but for writes all of the them have to go to same node which can be a hotspot. For objects which do not have writes or writes are very rare, a cdn type of caching or application level caching where many copies of the data are created is the way to go.
If you still want to solve it using Aerospike, one idea could be…
For one product, create multiple physical records and logically split the entity. Say, you want to sell 100,000 items of a product with key p, you can split them into 50 items with key p01-p50 and store the inventory as 2000 each When the user’s query hits, randomly choose one of the 50 keys from p01-p50 and let him buy. To give a consistent view of the product, a logic can be chosen based on the sessionid (for e.g. modulo 50 of sessionid) or some other parameter. This logic will work if it is not necessary to be too fair to the users as there is some form of randomness in this logic.
Let us know your thoughts about the above solution. Its not straightforward but could be a good workaround. If you have some good ideas, please let us know too.