It is usually avoided to keep any state within the process so that the process can be restarted or run in parallel, without any data loss. E.g. when your web app has two parallel processes that serve requests, and one process changes the average, this change will not be visible in the other process.
It is fine to keep cached data within the process, as long as you are aware under which conditions this data may be out of date and would have to be invalidated. For example, if the exact average is not very important, you might be fine if it is 10 minutes out of date.
Aside from caches that may be out of date, any state should be kept external. This would usually be the primary database, but you might combine this with an external key-value store, e.g. Redis or Memcached. You still have to keep this cache up to date, but at least it is shared by all processes.
A lot here depends on what scale you will be operating on. Averaging a few thousand reviews is not a big deal, and you probably shouldn't spend any time optimizing this. Similarly, if you are sure that you will never scale beyond a single process of your web app, keeping temporary caches within that process might be tolerable. Note that even low-end architectures (such as LAMP) already imply multiple parallel processes. Beyond that, the recommendations of the Twelve-Factor App (https://12factor.net/) become relevant, in particular the emphasis on a share-nothing architecture.