Serverless per promo e campagne lampo: scalare senza pensieri

È sera. Il team marketing ha messo online un codice sconto valido 48 ore. La spesa media sale, i click esplodono. Il traffico fa 30x in dieci minuti. I carrelli si bloccano a tratti. Le API iniziano a dare 429. Il team guarda i grafici. La paura non è perdere utenti domani. È perderli ora, nei prossimi 5 minuti.

Il serverless nasce per momenti così. Non ti compra la fortuna, ma ti dà elasticità. Tu paghi per richiesta. Il cloud scala in modo rapido. Però ci sono limiti, code, freddi “cold start”. E ci sono costi se sbagli settaggi. In questa guida andiamo dritti al punto, senza fumo.

Cosa troverai: pattern semplici che reggono i picchi, cache all’edge, code, idempotenza per i pagamenti, test rapidi, numeri da guardare, un playbook di 72 ore. Parliamo anche di privacy, di quote dei provider, e di come stimare i costi per 24–48 ore di fuoco.

Quello che non ti dice la brochure

La brochure parla di scala “infinita”. In realtà hai tetti per account, per regione, per servizio. Le funzioni possono partire a freddo e perdere 100–500 ms in più. Alcune partizioni di dati diventano “hot”. Le API esterne possono darti back‑pressure. Serve un piano B: code e degrado elegante.

Controlla con cura i limiti del runtime. Ad esempio, qui trovi come funziona lo scaling e limiti di Lambda. Ogni provider ha regole diverse. Verifica prima di lanciare una campagna lampo.

Fai difese chiare al bordo: throttling e rate limit. Muovi le richieste in una coda quando la sorgente spinge troppo. Le buone pratiche sono raccolte nelle linee guida di rate limiting. È meglio una risposta 429 pulita che un timeout lungo e costoso.

Scelte di architettura per picchi improvvisi

Pattern rapidi che salvano la notte

API stateless davanti, coda in mezzo, worker dietro. È un classico. L’utente ottiene un “ok, stiamo processando”. Il lavoro pesante va in coda. Il worker scala con il carico. Questo rende il picco liscio e protegge i sistemi lenti.

Container serverless con autoscaling sono utili per endpoint che restano caldi. Un esempio è l’autoscaling di Cloud Run. Tieni alti i limiti di concorrenza per risposte brevi e coste meno.

Funzioni all’edge riducono latenza per pagine e API leggere. Puoi fare cache su HTML e JSON che non sono personali. Guarda i Workers all’edge se hai pubblico globale. Metti TTL corti e invalida quando serve.

Feature flag e switch rapidi sono vitali. In caso di stress spegni parti pesanti: raccomandazioni costose, filtri dinamici, o immagini XL. Un flag può salvare un checkout in 5 secondi.

Per una visione meno “marketing” e più di sostanza, ecco una overview indipendente su cosa è serverless e dove ha senso.

Dati e storage senza sorprese

Per promo brevi usa dati a vita corta. Metti TTL su carrelli, token e link. Per letture veloci usa KV e cache. Per scritture intense distribuisci le chiavi. Evita partizioni “calde”. Per analytics usa una pipeline separata, asincrona, così non tocchi il percorso critico.

Osservabilità che parla chiaro

Segui i segnali d’oro: latenza, traffico, errori, saturazione. Tieni grafici semplici, con soglie nette. Un buon punto di partenza sono i segnali d’oro SRE. Aggiungi alert su lunghezza coda, tassi 5xx, e budget di errore.

Vuoi capire l’edge senza parole complicate? Questo post spiega in modo chiaro cos’è l’edge computing e perché aiuta con utenti lontani.

Matrice di scelta per campagne lampo

Qui sotto trovi una tabella pratica. Scegli il tipo di campagna, guarda pattern, coda, cache, test e obiettivi. I costi sono indicativi: ogni provider ha tariffe diverse e possono cambiare nel tempo.

Numeri che contano davvero

Latenza p95: è il numero da fissare in testa. Se p95 supera 300 ms per API core, la UX soffre. Guardalo per route, non solo in media.

Rapporto cache hit: 80% su contenuti pubblici è un buon inizio. A 90% la spesa scende molto. Se sei sotto 60%, rivedi le regole di cache.

Code: lunghezza e tempo medio in coda. Una coda oltre 30–60 secondi su lavoro critico è un segnale rosso. Scala i worker o riduci peso del task.

Budget di errore: definisci 0.5–1% sul periodo della promo. Se lo bruci in anticipo, riduci carico con flag o downscale di funzioni non critiche.

Playbook operativo: le prime 72 ore

T‑24h: preparazione secca

• Esegui test di carico su endpoint chiave con profilo realistico.
• Accendi WAF, rate limiting, e regole per bot.
• Pre‑riscalda funzioni e cache nelle regioni top.
• Imposta alert su p95, errori, lunghezza code, 429.
• Prepara flag per spegnere feature pesanti.
• Condividi un runbook di escalation con contatti e soglie.

Live 0–48h: occhi sui grafici, dita sui flag

• Monitora code ogni 5–10 minuti. Se la coda sale, aumenta i worker.
• Se vedi 5xx sopra soglia, attiva modalità “leggera” su pagine ad alto traffico.
• Riduci tempo di TTL su cache se i contenuti cambiano spesso.
• Se un provider impone limiti, metti back‑pressure lato gateway e mostra messaggi chiari.
• Traccia costi orari per evitare sorprese a fine evento.

T+24h: spegnimento pulito e retrospettiva

• Scala giù la concorrenza provisioned e i worker extra.
• Draina le code e riconsegna i falliti con calma.
• Segna numeri finali: p95, errori, costi, tasso di conversione.
• Scrivi un post‑mortem breve con 3 cose da fissare per la prossima volta.

Micro‑case e settori con picchi feroci

Ticketing: l’apertura alle 10:00 crea una valanga. La coda controlla il ritmo. Il token “slot” evita la corsa all’ultimo byte. Il gateway risponde sempre in pochi ms, il lavoro serio si fa dopo.

Retail: un video virale manda 50k utenti in un minuto. La cache edge regge le landing. Le API scrivono in coda. I worker aggiornano stock e conferme. La UX resta fluida e tu non bruci il budget.

iGaming: nei portali di recensioni si vedono spike netti in “bonus weekend” o con influencer. Qui una architettura serverless con code e cache edge evita colli e riduce drop in signup. Esempio concreto: guide e confronti su blackjack online casinò, con test A/B su landing lampo e messaggi chiari sul gioco responsabile. Tieni limiti, log puliti e idempotenza sui webhook di bonus.

Black Friday: chi fa e‑commerce sa che è un gioco di minuti. Per ispirazione su come gestire picchi enormi, leggi come lavora il team di Shopify Engineering. È un mondo diverso, ma i principi di base restano.

Costi senza sorprese

Il bello del serverless è pagare a consumo. Il rischio è far partire troppi task inutili. Fai due conti rapidi: richieste x costo unitario + storage x GB + egress. Aggiungi un 20% di cuscino per sicurezza. Se la cache fa 80–90% di hit, i costi crollano. Se fai molto I/O su DB con chiavi “calde”, la spesa sale. Taglia le scritture duplicate. Metti batch dove non serve risposta in tempo reale.

Un trucco: misura “costo per 10k richieste” prima della promo e tienilo come KPI. Se sale troppo durante l’evento, guarda log, hit di cache e retry che girano a vuoto.

Legal, privacy, pagamenti

Raccogli solo i dati che servono. Pulisci i log da PII. Metti il Consent Mode per analytics. Proteggi i pagamenti: usa chiavi di idempotenza per ogni tentativo. Qui trovi come gestirle con esempi chiari: chiavi di idempotenza nei pagamenti. Per gli errori, fai retry con backoff e tetto massimo. Non rifare ad oltranza.

Checklist di produzione in 60 minuti

• Abilita cache edge per landing e API pubbliche (TTL brevi, invalidazione chiara).
• Aggiungi coda tra API e servizi lenti. Imposta DLQ e metriche.
• Setta rate limit al gateway. Definisci messaggi 429 utili.
• Attiva provisioned concurrency solo su 2–3 funzioni calde.
• Crea 3 alert: p95, 5xx, lunghezza coda. Soglie semplici.
• Lancia un test rapido con test di carico con k6. Simula il primo minuto del picco.
• Prepara flag per spegnere funzioni costose in un click.

FAQ concrete

Che cos’è il serverless e perché è adatto alle campagne lampo?

È un modello dove non gestisci server. Paghi per uso. Scala in fretta. Per picchi brevi è ideale perché non tieni macchine accese tutto il giorno.

Come posso ridurre i cold start durante un flash sale?

Pre‑riscalda le funzioni nelle regioni top. Usa provisioned concurrency solo per endpoint caldi. Tieni pacchetti leggeri e poca inizializzazione.

Quali limiti pratici devo considerare?

Quote per invocazioni, concorrenza, connessioni al DB, e burst per account. Leggi le quote del tuo provider e prova con test. Se superi i limiti, attiva code e back‑pressure.

Quanto può costare gestire 1M di richieste in 24 ore?

Dipende da cache hit, peso delle funzioni e uscite di rete. In molti casi parliamo di decine o poche centinaia di euro. Con cache alta i costi scendono molto.

Che differenza c’è tra edge e region?

L’edge è vicino all’utente e serve contenuti statici o logica leggera. La region è il data center dove vivono i dati e i servizi pesanti. Insieme danno bassa latenza e affidabilità.

Come faccio un test realistico in meno di 2 ore?

Prendi 3 endpoint chiave. Crea scenari di spike veri (30x in 5 minuti). Usa un tool semplice. Guarda p95, errori, e coda. Aggiusta e ripeti una volta.

Autore e metodologia

Autore: architetto cloud e SRE. Ho messo in produzione stack serverless per retail, ticketing e media. Ho visto picchi 20–60x in minuti. In questa guida ho raccolto pattern che hanno retto in casi reali.

Metodologia: test con k6 e Artillery su scenari “spike” e “stress”, misure su p95, hit di cache, lunghezza coda e costi per 10k richieste. Ho citato fonti tecniche aperte. Limiti e prezzi possono cambiare. Ultimo aggiornamento: giugno 2026.

Nota: questa guida non è consiglio finanziario. Per il gioco, promuovi sempre pratiche di responsabilità e tutela dell’utente.