Stato duplicato in real-time costa più della sola RAM

Un contatore di velocità per carte di pagamento gira su Flink, calcola gli ultimi cinque minuti, poi pubblica il risultato su Redis: ogni aggiornamento fa serializzazione, attraversa la rete, aggiunge lavoro CPU che la bolletta della memoria non mostra¹.

Molte architetture real-time separano i ruoli. Kafka gestisce gli eventi. Flink processa. Redis serve lo stato più recente. Il database custodisce il sistema di record. Chi fa ricerca vettoriale aggiunge uno store vettoriale. Questa divisione offre flessibilità e scalabilità indipendente, ma crea costi quando i dati si muovono tra componenti o quando lo stato si sovrappone in più punti¹.

Flink mantiene stato indicizzato per sostenere il calcolo del contatore. Flink non è un layer di serving generale. La Queryable State è stata deprecata nella 1.18. Per questo molti pubblicano i risultati su Redis, che introduce un piano di serving con requisiti di scala e operatività propri. Lo stato di lavoro di Flink e il valore in Redis possono sovrapporsi senza coincidere. Ogni pubblicazione comporta serializzazione, traffico di rete e lavoro di elaborazione prima che i consumatori vedano l’aggiornamento¹.

La coerenza si complica quando l’app legge da repliche asincrone in più zone di disponibilità. Una replica è in ritardo. Un servizio vede una transazione non ancora rimborsata e approva un secondo rimborso. È un race check-then-act su stato replicato in modo asincrono. Se l’app chiama un servizio esterno di pagamento, serve idempotenza nelle richieste per evitare che i retry replichino il rimborso¹.

Due ritardi vanno distinti. L’export lag, tra il momento in cui il processore calcola un valore e quello in cui lo store di serving lo riceve. Il replica lag, tra repliche all’interno dello store di serving. Durante l’export lag, un’ondata di transazioni fraudolente può essere valutata su un conteggio vecchio. Nessuno dei due va confuso con la race che duplica i rimborsi¹.

Hazelcast evita la pubblicazione separata quando il calcolo gira direttamente sullo stato memorizzato. I suoi entry processor aggiornano in modo atomico le entry sul membro che detiene la chiave. Durante partizioni di rete, il sistema non è fortemente consistente. Per coordinamento più forte, Hazelcast offre strutture dati nel sottosistema CP basato su Raft. Non trasforma un’IMap ordinaria in una mappa fortemente consistente e non rende atomico un aggiornamento con un pagamento esterno. Anche sistemi separati possono usare coordinamento fortemente consistente¹.

La memoria domina spesso la discussione. CPU e rete contano altrettanto. Uno studio 2025 di UC Berkeley e Databricks, con assunzioni di prezzo su Google Cloud di circa 17 dollari al mese per vCPU e 2 dollari al mese per gigabyte di RAM, rileva che il caching in memoria riduce i costi operativi di 3 o 4 volte. I risparmi di CPU superano il costo della RAM aggiuntiva. Il confronto remoto contro cache collegata indica che comunicazione e serializzazione consumano CPU. Controlli di versione per lettura con garanzie più forti possono erodere gran parte del beneficio, quindi i confronti richiedono gli stessi requisiti di consistenza¹.

Un paper del 2019 di Google riporta una riduzione del 40% nella p99,9 di latenza per ProtoCache dopo il passaggio da uno store chiave-valore remoto a un’architettura che tiene logica applicativa e stato in memoria insieme¹.

Un calcolo a parte mostra il costo in memoria di due working set equivalenti. Con il prezzo assunto dallo studio, 400 GB valgono circa 800 dollari al mese solo di memoria, prima di backup, checkpoint e altra infrastruttura. Mantenere un importo equivalente sia nel livello di processamento sia in quello di serving raddoppia la cifra, anche se lo stato intermedio di Flink e i risultati pubblicati su Redis possono differire molto¹.

Per carichi che richiedono letture con version check a ogni accesso, il bilancio dei costi cambia ancora: parte del risparmio del caching può svanire quando si alza l’asticella della consistenza¹.