I'm in the planning stages of a web application that makes heavy use of data retrieved from a third party's REST API. This data is cached on the server and requested by clients via AJAX. The REST API has a rate limit, and I plan on using the token bucket scheme to adhere to it. However, I'm having trouble coming up with a thread-safe way of storing the bucket value. Because of this, I'm considering two technologies for my server-side needs. I only program as a hobby so...bear with me.
Here, I considered putting the bucket variable in the APCu cache, but I'm not entirely sure how thread-safe that is. I imagine a scenario: there is one token left in the bucket. Client A pulls the data from the cache, then client B immediately after. A notices there is one left, and subtracts a token, then B does the same, the bucket is at -1 and both think they're clear to request. If a bunch of threads do this, I break the limit. Is this a realistic scenario? Is there any better way to implement this API limit on a site-wide (not per-user) basis? I'd rather not resort to an outside script.
Node seems like it would be perfect, given the site architecture, but it's a huge shift in thinking. It has only one thread of execution, and there are also global vars that the docs say are local to the module. I assume that 'local to the module' means its available to only that module, but 'global' means any time that one module comes up in the event queue the global var will be there. Is this the case? If so, when the bucket is empty and the module must wait to place the request, that will block everything else node is doing, won't it? And if there are multiple node.js instances running, the global isn't shared between them, is it? I've seen several npm packages for rate limiting, but they all seem to be per-user.
I have some other questions about node as well, but this post is long enough already.