I think what's happening is that there is a server pool for that handles the inventory api and also the first pass availability check form the site (before you go into the actual checkout part)
I use the ip6plus python inventory checker which works great and it shouldn't be doing any caching on the client side but I do notice that sometimes it reports inventory late, and then it will hold into it for 15 minutes while the actual stock was sold out in 30 seconds. 15 minutes seems like a nice round number that describes an update timer somewhere in the system.
so I think it's hitting a server in the pool that is just getting the stock updates not right away. The actual checkout part of the process is much closer to real time and I think that explains why the check out process is erroring out for a lot of people because it's probably a single server or at least a very small server pool that is responsible for that last part of the check out process.
Although I do think that the location check in the check out is closer to real time, it's only the very final purchase button that is actually compared to the real-time stock.
Also, I think different servers in the front line pool are not updated at the same time. so I might be hitting 1 server with my local python script while iStock is hitting a different. so we may not be seeing the same data.
I would like to compare notes with iStock though to see if this meshes what you think is happening. Supposedly, the inventory gets updated in real time as units get scanned into the system, so it doesnt match the behavior we are seeing where big batches of stock appear and disappear in multiple locations at the same time.