Zřejmně je to dotaz v teoretické rovině. Tak proč nediskutovat.
Je třeba si uvědomit, co taková aplikace potřebuje. Pokud budu vycházet z klasické trojvrstvé struktury: persistentní úložitště (systém souborů, databáze), aplikační vrstva na serveru (PHP) a tenký klient (webový prohlížeč), tak:
Pokud nestíhá úložiště, je možné nastadit replikace dle typu zvoleného úložiště. SQL lze snadno replikovat jako master - slave. Dotazy mohou jít na farmu slavů, inserty na master. Nutná přestavba aplikace, pokud se s tím nepočítá přímo v návrhu. Některé KV DB umí i replikaci master-master, pochopitelně s omezením dle CAP. Storage vrstva se může také realizovat čistě jako distribuovanou memory DB (Redis) a persistenci řešit jinak (nebo nijak a spoléhat se jen na vzdálené lokality).
V případě souborů na disku existují clusterované systémy souborů (GlusterFS). Každá aplikace by měla mít přístup ke všem souborům. (Opět, jako u každé distribuované aplikace, je zde omezení dané CAP.)
Též je možné mezi storage a aplikaci nasadit cache (memcached). Nejrychlejší dotaz je takový, který se nemusí vykonat. Toto je asi nejčastější optimalizace na straně storage. Nějaká forma cache mezi diskem a aplikací.
Aplikace může běžet ve více instancích, pokud je zachována konzistence úložiště.
Před aplikacemi může běžet reverzní cachující proxy (squid, nginx). Což je nejčastější optimalizace mezi webovým serverem a webovým klientem. V případě více instancí aplikace lze před farmu aplikačních serverů nasadit také loadbalancer. V takovém případě může mít loadbalancer klidně jednu IP a za ním být spousta instanací aplikace. Loadbalancer může být také ve více instancích pro high avail.
Jinými slovy, pokud je zachována konzistence dat na straně storage, aplikace může běžet v mnoha instancích za jedním nebo více loadbalancerů.