In base alla mia esperienza, il commento di @ RobertHarvey che "nessuno di noi può prevedere tutti i possibili problemi" è generalmente corretto e, come suggerisce, dovresti probabilmente prototipare la tua soluzione e impostare buone metriche per capire dove deve essere scalata .
Detto questo, penso che sulla base della tua descrizione il tuo approccio sia ragionevole. Se si desidera avere un'API RESTful, tale API dovrà accettare un POST o PUT con le immagini che devono essere migliorate. Non si desidera bloccare la richiesta, quindi accettarla immediatamente e rilasciare il file da qualche parte in modo che il processore di immagini possa elaborarlo in un secondo momento (su un processo diverso o anche su una macchina diversa). Quel "da qualche parte" potrebbe essere un secchio S3 o una posizione del file system o una coda di messaggi o dovunque; Non penso che possiamo valutare cosa è meglio per te in quel caso.
Ciò che guarderei in termini di prestazioni e scalabilità sono:
1) Ho diviso i componenti in modo tale che I solo abbia bisogno di espandere i punti che sono il collo di bottiglia. Ad esempio, se ci si aspetta che sia necessario eseguire più macchine che utilizzano peApp, è necessario che sia isolato e contenga solo il codice necessario per eseguire tale processo.
2) Dato il n. 1, il mio altro processo ha l'infrastruttura di cui hanno bisogno per poter eseguire senza iniettare la logica negli altri componenti inutilmente. Ad esempio, si aggiunge un MQ perché non si desidera che l'app REST invii direttamente peApp. questo ha senso.
Oltre a questi due fattori, è molto ottimizzante per il tuo problema specifico. Se sono io, inizierei senza il MQ francamente, e ho appena eseguito il peApp ping su una posizione ben nota (ad esempio un bucket su S3) per ottenere il file "successivo" nella pila da elaborare. Osserverei il ritardo dei tempi di caricamento della CPU (GPU) e così via per decidere se devo ridimensionare o scalare. Quindi risolverei il problema successivo quando questi verranno risolti.