La codebase non è completa e manca di molti dettagli, non ho avuto la possibilità di collegarmi ad un account aws e di costruirla incrementalmente pertanto va intesa come una prima stesura.
An AWS Stack based on Beanstalk.
L'architettura della soluzione è stata guidata dal concetto di MVP (Minimal Viable Platform) pertanto è stato scelto di partire da AWS Elastic Beanstalk (PaaS). Questo permette di soddisfare i requisiti delegando ad AWS molte tematiche per velocizzare il time to market; chiaramente tale scelta comporta un minor controllo sui costi e lascia meno margine per migliorare l'architettura della applicazione rispetto a soluzioni come ECS ed EKS.
Simplified View.
Il punto di ingresso della soluzione è AWS CloudFront in modo da soddifare la disponibilità globale del frontend esponendo allo stesso tempo le api della parte backend. Attualmente l'applicazione è un monolite basato su django ma nulla vieta di scomporla in più servizi esposti da un api gateway.
Sia cloudfront che il bilancitore sono configurati per gestire le richieste esclusivamente in https.
Il database ha una replica in sola lettura.
Per la gestione dei tasks asincroni ci si è basati su AWS Lambda, i sorgenti si trovano nella directory tasks. E` stata aggiunta una dead letter queue, uno scheduler periodicamente chiamerà la lambda contenuta in dlqlambda che avrà come compito di spostare i messaggi dalla dlq alla coda che serve a richiamare i singoli tasks.
Async Engine.
Il flusso di lavoro è pensato per utilizzare git (trunk based development) e di affidarsi a github actions o dagger per le pipeline in modo da aderire al concetto di continuous integration e delivery. Bisogna innanzitutto pubblicare l'immagine del backend e generare con npm(react) l'applicazione frontend. L'ultimo step sarà quello di richiamare il cdk per il rilascio che può essere facoltativo.
Per quanto riguarda il monitoraggio si potrebbe pensare nella fase iniziale di trattare il tutto come una "black box" e di utilizzare la versione semplificata dei golden signals (RED).
Non ho particolari competenze riguardo a tematiche di intelligenza artifiale, supponiamo che un architettura plausibile sia quanto descritto da questo articolo; in tal caso il principale problema dipenderebbe dal database relazionale.
Il database potrebbe essere gestito all'interno del cloud provider oppure disponibile nel datacenter del cliente; in un cloud privato ad esempio. In entrambi i casi suggerisco di avere una duplicazione del dato. La duplicazione si ottiene in modo del tutto naturale nel caso l'applicazione fosse basata su paradigmi event driven (Event Sourcing, CQRS) viceversa si può optare per ETL o CDC (Capture Data Change).
L'idea è sfruttare l'eventual consistency delle "moderne architetture" e portare il dato il più vicino possibile a dove deve essere analizzato.