Un'applicazione di ticketing è in esecuzione su un cluster Amazon ECS ed è distribuita tramite CloudFront. Un singolo servizio ECS è l'origin di CloudFront. L'app limita il numero di utenti attivi nel flusso di acquisto; gli utenti autorizzati sono identificati da un attributo crittografato nel loro JWT; gli altri vengono indirizzati a una sala d'attesa. Sotto carico elevato, la sala d'attesa stessa sta causando un carico che interrompe gli acquisti dei biglietti. Quale modifica fornirà l'esperienza di acquisto dei biglietti più affidabile durante un carico elevato?

La risposta corretta è creare un servizio ECS separato per la sala d'attesa e utilizzare una CloudFront Function per il routing. Separare la sala d'attesa in un servizio ECS dedicato con la propria configurazione di scalabilità isola il carico, impedendo che la sala d'attesa sovraccarichi l'applicazione di ticketing. Le CloudFront Functions (o CloudFront Lambda@Edge) sono ideali per ispezionare i JWT e reindirizzare le richieste in base alla logica aziendale (come l'autorizzazione degli utenti) molto vicino all'utente finale (edge), riducendo la latenza e il carico sull'origin. Le altre opzioni sono meno efficaci. La prima opzione, pur separando i servizi ECS, fa sì che il servizio di ticketing inoltri le richieste alla sala d'attesa, mantenendo un potenziale punto di strozzatura nel servizio di ticketing. Le opzioni che propongono la migrazione a EKS introducono complessità e costi aggiuntivi senza risolvere il problema fondamentale del routing a livello edge e dell'isolamento del carico in modo più efficiente rispetto a CloudFront Functions e ECS.