Caching is the classic memory-time tradeoff, everything from memoizing a function, to DNS caching, to storing a web resource that didn&#x27;t change.<p>I think that, if a cache is combined with a push indicating a change, then it&#x27;s basically a local &quot;eventually consistent replica&quot; which catches up as soon as there is a connection to the source of truth.<p>Seriously, many times you are READING data which changes rarely (read: every X minutes &#x2F; hours &#x2F; days). So, in the meantime, every code path that will need access to the data may as well look in the local snapshot first.<p>The question about consistency is an interesting one. The client&#x27;s view of the authoritative server state may be slightly out of date, when the user issues a request. If certain events happened in the meantime that affect the user&#x27;s view, then the action can just be kicked back to the user, to be resolved. But 90%+ of the time, the view depends on 10 things that &quot;change rarely&quot;, so a cache is a great improvement.<p>Related issues involve batching &#x2F; throttling &#x2F; waiting for already-sent requests to complete.<p>PS: That was quick. I posted this and literally 10 seconds later it got a downvote.