CasiScenario
Ordini che non si perdono
Un e-commerce che sotto i picchi va in timeout e perde ordini.
Scenario tipo: non è il racconto di un cliente, è come imposterei un progetto di questo genere. I numeri sono indicativi.
01Il contesto
Un e-commerce gestisce ordini, fatture e email di conferma in un'unica chiamata sincrona. Durante le promozioni il servizio di fatturazione rallenta, la chiamata va in timeout e alcuni ordini restano a metà.
02La decisione
L'API accetta l'ordine, lo salva e pubblica un evento su EventBridge, poi risponde subito al cliente. Fatturazione ed email ascoltano l'evento ognuna con la propria coda SQS, così un rallentamento della fattura non blocca più niente. Le Lambda sono idempotenti, con una chiave per ordine, e i messaggi che falliscono tre volte finiscono in una dead-letter queue con un allarme.
Alternative scartate
- Più server dietro la stessa chiamata sincrona: sposta il problema al prossimo picco.
- Una coda unica per tutto: più semplice, ma un consumatore lento rallenta anche gli altri.
03Il risultato atteso
- Ordini persi in test di carico 10xnessuno
- Tempo di risposta al clienteindipendente dalla fatturazione
- Errorivisibili nella DLQ, con allarme e possibilità di rilancio
04Cosa rifarei diversamente
Scriverei il contratto degli eventi, con nomi e campi, prima del codice. Gli eventi sono un'API pubblica tra i team.
Hai un problema simile? Mandami i tuoi numeri e ti dico come lo imposterei.