This is a fantastic question. I don't know enough about the internals of Shiny to stay for certain, but I thought it used a more standard "callback" based reactivity paradigm (rather than continuous polling). I.e. when a value is changed, then it "pushes" through the dependency tree rather than waiting for the children to "poll" / "pull" the update.
That's how I think of it, at least
Again, I do not know enough about the internals to say for sure what the actual implementation looks like. I will say for the poll-approach, you can do things like invalidateLater(), but I do not know if that is super relevant to your question.
I will say that, regarding traffic, Shiny has been shown to scale well (linearly, like most production-capable web frameworks) to 10,000 concurrent users. For the demo, the app was hosted on RStudio Connect:
https://www.rstudio.com/resources/videos/scaling-shiny/
There are new tools for load testing if you are trying to prepare for a certain level of performance:
Joe also shared a talk at rstudio::conf about what some of the common issues with performance are. Spoiler: I/O and caching 
Hope that helps! And maybe someone more knowledgeable of the internals will come here and enlighten us about the actual implementation of Shiny's reactivity! 