PHP
Your cache read/write is a critical section. You'll need to protect it with your choice of mutual exclusion to prevent the false read you describe. For better or worse, locking in PHP isn't straightforward. The cross-platform solution uses a file (guaranteed to cause grief if your server gets busy). Beyond that it depends on both the OS and server configuration. You can read more here: https://stackoverflow.com/a/2921596/7625.
Node.js
Since Node is single-threaded, you don't need a lock unless you execute an async operation (I/O and related). This doesn't necessarily solve all your problems, however. Read more below.
All
As described, you have a looming big problem. I see a hunch when you say, "...that will block everything else node is doing, won't it?" That's not the exact problem -- you can create a non-blocking wait. But does waiting solve your problems? Not really. If your site is really busy, each waiting request increases the chance the next request will have to wait. The requests are piling up... If there's enough traffic, the waits will get longer and longer. There will be timeouts. There will be hand-wringing. There will be tears.
This is an equal opportunity problem. Neither PHP or Node are immune. (In fact, everyone's vulnerable given a throttled resource and the approach you describe.) A message queue doesn't save you. All a message queue gets you is a bunch of queued requests that are waiting. We need a way to dequeue those requests!
Luckily, this can be pretty straight-forward if we push more responsibility to the browser. With a little re-jiggering, the response back to the browser can contain a status and an optional result. On the server, send a "success" status and result if you get an API token. Otherwise, send a "not yet" status. In the browser, if the request is successful proceed as normal. If not, proceed as you see fit. If you're sending requests asynchronously, you can retry in a half second, then a full second, then... There are great opportunities for giving the user feedback. Beyond great feedback, this approach also keeps server resources to a minimum. The server isn't punished for the third party API's bottleneck.
The approach isn't perfect. One not-so-nice feature is that requests aren't guaranteed to resolve in the order received. Since it's a bunch of browsers trying and retrying, a really unlucky user could continually lose their turn. Which brings me to the penultimate solution...
Open Your Wallet
I'm guessing that your third party API is throttled because it's free! (or inexpensive) If you really want to wow your users, consider paying for better service. Instead of engineering your way out of the problem (which is sorta cool, sorta chintzy), fix the issue with cash. Remember, many, many operations that run on-the-cheap feel cheap. If you want to keep your users, you don't want that.
Would you not be wanting to cache the data on backend somewhere then allow the Ui to request this, rather than setting off a chain of calls every time.
You can then reduce the internal calls to one set per 3s or whatever the refresh rate is?
Having the calls chain through the system is good for testing, caching lets you scale up.
Best Answer
PHP is a programming language. You use a web-server like Apache to handle HTTP requests and depending to your settings your web-server runs PHP in the background.
Node.js is an environment to run JavaScript. JavaScript is the programming language that you are building your stuff on it. Here Node.js is your web-server that handles HTTP requests.
Node.js doesn't create a new process to handle each request; That's why you see all the outputs in one place. It loads your file once and then serves all users with the same code.
In PHP, a fresh copy of file (either from cache or disk) will be used to serve each request which means re-initialising everything, including your variables, etc.
In JavaScript, this code will only hold the last value assigned to it:
If you want to keep the IP address of each individual users, you should do it either like this:
Or:
You should create a new User instance every time you handle a new request. It can't be one global variable/object, or the value will be replaced anytime you handle a new request.
(These are just example snippets to demonstrate the point)