Data Storage

Event store per history immutabile; Postgres con viste materializzate per read model veloci derivati dagli eventi.

Approfondimento

Definizioni, contesto e collegamenti tra concetti — leggi prima del palcoscenico interattivo se parti da zero.

Event store e read model

L’event store tiene la storia immutabile. Il read model (viste, summary, dashboard) è una proiezione derivata, spesso denormalizzata per query veloci. Il worker di proiezione consuma lo stream o una coda di integrazione e aggiorna tabelle o viste materializzate.

Postgres offre viste materializzate e refresh concorrente: utile per reporting se accetti una finestra di freschezza. Valuta indici unici richiesti da `REFRESH MATERIALIZED VIEW CONCURRENTLY` e pianifica finestre di refresh vs carico.

Costi e operatività

Eventi + MV duplicano dati: misura crescita, partiziona storico e comprimi archive. Definisci ownership: chi risponde se la MV è stale? come si backfill dopo un bug di proiezione?

Il client tipicamente legge solo il read model già proiettato (`/api/.../summary`), non lo stream grezzo, salvo tool admin o debug controllati.

Palcoscenico

Step 0/3 — CloudEvent in transito

ServerWorker proietta eventi

BrokerStream interno (opzionale)

ClientQuery read model

{ "view": "order_summary_mv" }

Contratto e codice

Schema JSON basato su CloudEvents 1.0, poi snippet server e client.

{
  "specversion": "1.0",
  "source": "/orders-service",
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "time": "2026-05-13T12:00:00.000Z",
  "datacontenttype": "application/json",
  "type": "com.example.readmodel.refresh",
  "data": {
    "view": "order_summary_mv",
    "basedOnStream": "orders:ord_1",
    "lastAppliedPosition": 1288
  }
}