Quante volte avete subito timeout, rallentamenti o crash durante l’invio massivo di email o l’esecuzione di task “pesanti”? In questo talk partiremo da un’applicazione monolitica che gestisce web e invii direttamente nello stesso processo, con problemi di performance e manutenibilità. Vi mostrerò come, grazie a un’unica immagine Docker parametrica (entrypoint “run_web” vs “run_worker”) e a un’architettura event-driven basata su Redis Queue, abbiamo eliminato i colli di bottiglia, separato i workload e ottenuto un sistema resiliente e auto-scalabile su AWS Fargate. Nel dettaglio vedremo quando e perché spostare task asincroni in code, come costruire il Dockerfile unificato, definire Task Definition e Service su ECS, e configurare auto-scaling basato su CPU e lunghezza della coda.

Learning Outcomes
- Riconoscere i sintomi di un’architettura monolitica che non scala (timeout, memory leak, bump di traffico).
- Quando e perché spostare workload asincroni su code (Redis/RQ) anziché eseguirli nel thread web.
- Costruire un’unica Docker image con ENTRYPOINT parametrico per web e worker.
- Progettare Task Definition e Service su ECS Fargate per workload differenziati e auto-scaling.