Di solito si evita di mantenere qualsiasi stato all'interno del processo in modo che il processo possa essere riavviato o eseguito in parallelo, senza alcuna perdita di dati. Per esempio. quando la tua app web ha due processi paralleli che servono le richieste e un processo modifica la media, questa modifica non sarà visibile nell'altro processo.
È opportuno mantenere i dati memorizzati nella cache all'interno del processo, purché si sappia a quali condizioni questi dati potrebbero non essere aggiornati e dovrebbero essere invalidati. Ad esempio, se la media esatta non è molto importante, potresti stare bene se è 10 minuti non aggiornato.
A parte le cache che potrebbero non essere aggiornate, qualsiasi stato dovrebbe essere mantenuto esterno. Questo di solito è il database principale, ma potresti combinarlo con un archivio di valori-chiave esterno, ad es. Redis o Memcached. Devi ancora mantenere questa cache aggiornata, ma almeno è condivisa da tutti i processi.
Molto qui dipende da quale scala su cui opererai. Averne una media di poche migliaia di recensioni non è un grosso problema e probabilmente non dovresti perdere tempo a ottimizzarlo. Allo stesso modo, se sei sicuro di non essere mai al di là di un singolo processo della tua app web, mantenere le cache temporanee all'interno di quel processo potrebbe essere tollerabile. Si noti che anche le architetture di fascia bassa (come LAMP) implicano già più processi paralleli. Oltre a ciò, le raccomandazioni dell'App Twelve-Factor App ( link ) diventano rilevanti, in particolare l'enfasi su un'architettura share-nothing .