Ich denke nicht das die Datenmenge das Problem ist. Ich tippe auf die Anzahl der maximal möglichen Sessions am Webserver, bzw. die rechtzeitige Freigabe eben dieser. Das wäre durch einfache Konfiguration lösbar, sofern der Zugang exklusiv für die App zur Verfügung steht. Ist das (wie so oft bei VW) shared und es gibt Anwendungen die eine lange "alive"-Zeit benötigen, dann müssen erst alle ins Boot geholt werden.
Ja, irgendwas in der Richtung wird es sein können. Die Datenmenge sollte nicht das Problem sein. Allerdings kann so ein Server immer nur eine gewisse Anzahl (paralleler) Vorgänge verarbeiten. Irgendwann (bzw. meist ziemlich schnellI) braucht man also irgendeine dynamische Lastenverteilung. Total normal. Genau wie ein sinnvolles Caching (idealerweise schon auf den Clients), um die Gesamtlast zu reduzieren.
Wenn die Softwarearchitektur eine solche Skalierung aber nicht oder nur sehr schwer zulässt oder es interne Bottlenecks gibt (z.B. ein internes, zentrales IAM) ist der Ofen schnell aus. Wenn die Software nicht skalierbar ist, kann man das Problem irgendwann nicht mehr mit immer mehr Hardware "lösen".
Leider wird letzteres jedoch viel zu häufig gemacht, da es zunächst funktioniert und meist die einfachste Möglichkeit ist.
Eine weitere Maßnahme wäre auch eine clientseitige Kontrolle der Serververfügbarkeit. So könnte man nicht nur bessere Fehlermeldungen ausgeben "Es gibt aktuell technische Problem, wir arbeiten daran.", sondern auch die Anzahl an Requests durch ungeduldige "Aktualisierer" stark reduzieren.
"Aktuell keine Serververbindung möglich. Nächster Versuch in 120 Sekunden.".
Ansonsten kann es schnell zu Kettenreaktionen kommen. Durch viele parallele Aktualisierungsversuche (viele Menschen versuchen gleichzeitig immer wieder den Status neu zu laden) schießen die Requests in die Höhe und zwingen ggf. noch weitere Komponenten in die Knie.