I hope you're happy with yourself
@TheGuyThatMakesSwords, I blew the dust off of Visio so I could diagram this for you, look how great this diagram is! Keep in mind that this doesn't talk about APIs, reverse proxies, transparent forwarding, or static content caches all of which Disney is probably doing. If you're talking about the MDE app, erase web servers and write in APIs, the difference is just the protocol and authentication mechanisms.
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.
For example..
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.
