Oscar Mayer Memer
Why would I do something that I know wouldn't help? Refreshing just tells the application to send another message to the bus, it's possible they have an application cluster that's not responding and the load balancer health check hasn't pulled it from the pool yet. If refreshing works it's the luck of the draw that it's going to another cluster in the pool, but at the same time it's stacking up requests and if enough people start refreshing constantly while they're not running at full capacity it may slow everything down to a crawl.
Ok, so.. Whenever you go to a really big website like Disney, the page that you see in your browser has to be generated by something that looks like that picture. Yes, my diagram does look better than some server rooms.
How that works, well that's a topic for another day.
Anyway, so you've gone to the website or opened the app and now you want to go look up some information about your vacation. Great!
Let's say you want to look at your dining reservation, so you tap dining reservations.
We're going to assume you are already logged in, so MDE or your browser has a session cookie or some identifier that defines who you are.
The first thing the web application thread probably does is send a message to the bus asking about what queues are available for information about dining reservations.
Once it has a list, it picks one and sends a message to the queue of something like "Hey, send me the dining reservations for @TheGuyThatMakesSwords!, by the way I am (session id)"
The web application thread now stops work and waits for a return message from the bus.
An application server thread sees the message in the queue, reads it and it may or may not let the web application know that it's working on it.
Now it connects to the database that holds all of the dining reservations, and queries the list of dining reservations for @TheGuyThatMakesSwords.
When it has the data, it needs to create a message and send it back to the queue where the web server can find it, tagging it with with the same session id.
The web application thread wakes up when it sees the returned message, reads it, and sends you back the reservations that you have booked in the system.
Now, let's say that the application server that services that queue for whatever reason is down so it can't pick up the message, or it can't access the database, maybe it has so many requests that it can't handle any more so it's just really really slow causing the the web server thread to decide that it took too long so returns the website without the reservation.
Now let's say that you're refreshing the page 20 times a minute for the last 10 minutes so now there are potentially 200 requests in the queue for your dining reservations depending on how the session data is managed. Since the web server has a list of queues, sometimes it puts messages in a different one which is faster for whatever reason and you get results back.
Meanwhile you * 100,000 other people refreshing are causing that much more work for the backend.
Eventually those queues that were still responding fast stop responding fast.
..so what I'm trying to get at here is stop doing that please.