02 - Esercizio Scaling Improvviso

Scenario "BoutiqueBox"

L'azienda

BoutiqueBox è un piccolo e-commerce indipendente che vende articoli artigianali (saponi, candele, oggettistica). Esiste da 2 anni.

Numeri attuali

  • 1.000 visitatori unici al giorno
  • 30-50 ordini al giorno
  • 500 prodotti a catalogo, ognuno con 3-5 foto

Architettura attuale

  • 1 VPS singolo (4 vCPU, 8GB RAM, 200GB SSD) hostato in Germania, €40/mese
  • App Express monolitica che gestisce:
    • frontend SSR (template EJS, niente SPA)
    • API REST per catalogo, carrello, checkout, account
    • pannello admin per caricamento prodotti, ordini, fatture
    • worker interno che manda email transazionali via SMTP sincrono
  • PostgreSQL sullo stesso VPS, schema con users, products, orders, order_items, sessions
  • Sessioni utente salvate nella tabella sessions (cookie con session_id)
  • Foto prodotti servite dal disco locale (/uploads/...)
  • Pagamenti: chiamata HTTP sincrona a Stripe durante il checkout, l'utente aspetta la risposta
  • Email: nodemailer sincrono, una alla volta dopo ogni evento (conferma ordine, conferma spedizione, password reset)
  • CDN: nessuna
  • Cache: nessuna (a parte HTTP cache headers basici sulle foto)
  • Deploy: git pull && pm2 restart — downtime di 5-10 secondi a ogni deploy
  • Backup: dump SQL notturno su Backblaze
  • Monitoring: Uptime Robot pinga / ogni 5 min

Una fortuna/sfortuna

Un'influencer con 2 milioni di follower pubblica un reel TikTok + Instagram sul brand alle 14:00 di giovedì. Entro le 20:00 il traffico schizza:

  • Visite web: ~1.000/giorno → 100.000/giorno (proiezione)
  • Ordini: 30-50/giorno → 3.000-4.000/giorno (proiezione)
  • Picco di utenti concorrenti: ~5-10 → ~200
  • L'effetto si stima duri 2-8 settimane prima di stabilizzarsi su una "nuova normalità" di 5-10x rispetto a prima.

Il giorno dopo (venerdì mattina) voi siete i consulenti chiamati d'urgenza. Avete il weekend per progettare la nuova architettura.

Requisiti

  1. Sopravvivere alle prossime settimane di picco (~100x traffico)
  2. Restare entro costi ragionevoli (non potete decuplicare il budget hosting di colpo)
  3. Deploy senza downtime: ora i clienti notano se il sito sparisce per 5 secondi
  4. Tenere in considerazione i numeri previsti dopo l'assestamento

Cosa dovete produrre

  1. Lista dei punti di rottura: cosa cade per primo nell'architettura attuale, in che ordine, con quale impatto sul business
  2. Lista di interventi da eseguire. Valutazione di:
    1. urgenza
    2. costo
    3. impatto (beneficio o rischio se non implementato)
    4. necessità futura
  3. un diagramma del sistema "rifatto"