Shiny applications are a combination of a UI that runs in a browser client that relies on the back-end server to execute code in R for which it needs, naturally, the R session. True to its origins as an interactive desktop tool, R is single-threaded, so it cannot just spawn processes as needed to keep up with demand.
The fine folks at Posit keep the lights on by licensing industrial-strength versions of their free open-source products that better manage the challenges of multiple concurrent users. I assume that if you were using the paid version, you'd be getting official, rather than community, support with this challenge. You might want to contact sales to get pitched on how the paid offerings might solve your problem. I feel reasonable confident that they won't oversell, because of the subscription model. And they are good folk.
I ran my first server in 1996 on an SGI workstation over a 56K fractional T1 and, on fewer cycles and less memory and storage than any iPhone, comfortably ran DNS, HTTP, HTTPS, SMTP, LDAP, certificate, proxy, reverse proxy and newsgroup servers concurrently without breaking a sweat. Because of light load and client side I/O boundedness. No one's I/O bound anymore, it seems, it's all CPU bound. Hence the need for bare metal speed, which is not something R provides.
This brings me to raise the question—what problem does Shiny solve for your client? If it's a production-level platform (think DMV database queries) involving typical business logic activities mainly revolving around arithmetic to do things like comparing this month to last month, Shiny's pretty face is nice, but R's capabilities are 99.99% wasted. Yes, R can do this stuff, but so can almost any other language. With WASM, you can even do it all in browser.
On the other hand, if it's research-level stuff to develop service demand volatility models, the boffins working on it neither need nor want Shiny. They want to do things in R on the fly using every known statistical tool that has survived contact with practice. That's R's "core competency"—the depth of its tool bench.
My take is that the places where Shiny is strong are in ad-hoc team level projects and in prototyping production apps, which are likely to be lightly loaded. My public sector experience is that their tech uptake tends to be a ponderous process. Which bring me back to the question: Is Shiny the right tool for this job?