Questa è la frase
Altri record possono essere inseriti in qualsiasi istante da più utenti simultaneamente
che ha la ripercussione più pesante, dal punto di vista tecnico.
E' anche fondamentale capire se questi inserimenti sono tra loro collegati, oppure no. In sostanza se determinano delle race, oppure no.
"Migliaia di richieste simultanee" implicano pochi millisecondi per essere servite, ciascuna.
Il che significa sia una esecuzione sul database particolarmente rapida, sia un "qualcosa" in grado di riportare la risposta in pochi millisecondi.
Di nuovo la situazione può diventare banalmente ingestibile anche solo per la
quantità di dati da trasferire.
Se essa è molto grande allora hai problemi difficili da affrontare, con qualsiasi hardware.
Supponiamo, per fare i conti della serva, di avere 1.000 richieste al secondo (che, in media, ti assicuro non sono poche, parliamo ad esempio di un sito con 1 milione di utenti contemporanei).
Supponiamo però che ogni richiesta implichi una risposta da 1MB ciascuna (che è parecchio).
Con questo banale esempio vedrai che ti serve "qualcosa" in grado di maneggiare 1MBx1000=1GB al secondo, attraverso poi lo stack TCP.
Qualcosa di molto, ma molto, ma molto raro (ne ho uno qui proprio ora sulla scrivania da consegnare in settimana, circa 50K euro, non è mio, lo sto solo preparando).
Penso che macchine del genere si affittino sui 6.000 euro al mese.
Ovviamente il carico medio per secondo sarà molto più basso, ma dovrai limitare di gran lunga anche l'IO, non più di qualche KB, e comunque avrai latenze di ogni genere.
Insomma è come chiedere "come si progetta un aereo di linea" ?
Non è proprio facilissimo.
Su questo
In altre parole: implementare un'applicazione che deve soddisfare migliaia di utenti contemporaneamente NON E' cosa per persone NON ESPERTE: servono PROFESSIONISTI.
... aggiungo ... che abbiano esperienza proprio in questo ambito