Questa è una domanda a risposta aperta con molte possibili risposte che dipendono da cosa stai cercando di fare. Tuttavia aggiungerò alcune cose come risposta, poiché un commento non sarà abbastanza grande.
Il servizio fungerebbe da pool di connessioni al database (penso che oltre 2000 connessioni su un database possano causare problemi);
Si, questa è una buona idea. Mantenete aperto un numero minore di connessioni e le riutilizzate quando arrivano richieste al servizio. Ma devi sapere quanto saranno servite le richieste veloci e quanto ogni richiesta utilizza il database, altrimenti un piccolo pool può essere facilmente esaurito e altre richieste verranno bloccate in attesa del rilascio di una connessione al database.
La memorizzazione nella cache può essere utile in questo caso, per restituire dati già recuperati (come ho detto, dipende da cosa stai cercando di fare - se le query sono uniche non puoi memorizzare molto nella cache).
Si noti inoltre che la dimensione del pool verrà moltiplicata per il numero di servizi messi in atto. Alcuni servizi ed è possibile utilizzare dimensioni di pool di database di grandi dimensioni; più servizi e devi ridurre le dimensioni del pool, in modo da avere lo stesso numero di connessioni aperte al database, nel complesso.
È possibile avere un database con log shipping ad altri database di sola lettura per servire alcune query;
Il database può facilmente diventare il collo di bottiglia. Troppe connessioni e / o troppe query e puoi interromperle. A quel punto, non importa che sia possibile ridimensionare orizzontalmente i propri servizi su qualsiasi numero. Tutte le richieste alla fine raggiungeranno lo stesso database.
Esistono vari modi per proteggerlo: memorizzazione nella cache di cui ho già parlato (dipende dal tuo caso d'uso), duplica alcune informazioni su altri server per servire alcune domande come dici tu, CQRS (dipende dal tuo caso d'uso), usa un rapporto relazionale vs non relazionale (dipende nuovamente dal caso d'uso), ecc.
Si noti tuttavia che quando si distribuiscono dati di questo tipo, il teorema CAP inizia ad applicarsi. Sii consapevole di ciò poiché potresti dover scendere a compromessi tra coerenza e disponibilità.
Si ridimensionerebbe meglio in quanto possiamo aggiungere più macchine per eseguire i servizi REST;
Sì, il servizio REST si ridimensionerà, ma come ho detto sopra, se non si protegge il database, ciò può facilmente diventare un collo di bottiglia.
È possibile utilizzare HTTPS con compressione per motivi di sicurezza e risparmio di larghezza di banda;
Sì, così come altre cose ... forse vuoi l'autenticazione / autorizzazione in seguito, ecc.
È possibile apportare alcune modifiche centralizzate su entità aziendali senza ridistribuire le macchine 2000+;
Sì, ma fino a un certo punto e non tutti i tipi di modifiche. Se si apportano modifiche sostanziali, è necessario aggiornare anche i client. Pensa quindi a una strategia per aggiornare i client all'ultima versione o se permetti ai client più vecchi di continuare a lavorare e utilizzare l'applicazione.
Si integra meglio con altri sistemi (basta indicarlo al servizio REST).
Sì, ma ciò significa client per il tuo servizio che forse non puoi controllare.
Se si esegue una modifica sostanziale e si dispone di una buona strategia per aggiornare i client JavaFX 2000+, nessun problema. Ma se esistono altri client e non si ha il controllo su di essi, potrebbe essere necessario implementare il controllo delle versioni sul servizio REST e supportare più di una versione fino a quando tutti non possono eseguire l'aggiornamento alla versione più recente.
Come ho detto, dipende da cosa stai cercando di fare. Nel complesso, la tua è una buona idea. Ma tieni presente che le cose non verranno gratis solo perché attacchi un servizio REST di fronte a un database.
Solo i miei 2 centesimi!