Yes, naturally caching is about speeding up and reducing load.
Caching has several implications though. For one, due to reducing load, it reduces the DoS attack vector, as the attacking sources would end up draining it’s closest nodes, instead of the entire route to the data source.
It is even a quite often mentioned benefit of caching. So there is a security side to it also.
I’m not sure why you now say there is no need to keep cache up to date, considering this:
But, anyhow, reservation systems are often designed to not need 100% consistency, they even do overbooking, and solve it in other ways. There is always eventual consistency, all data is always stale. When you see it on the screen, it might change in the db, even if you sit right on top of the db.
Anyway, what I was writing about, was that having both consistency and protecting from DoS is tricky, because the moment you do a request all the way to the source, even if it is just for checking version (which of course needs to go all the way, next node is also stale), then you are opening up a vector, since it is then possible to overload (it needs more resources, than if more data than just version was fetched, but it is then a matter of a factor times input resource).
If you wanted to remove that all together (not considering with what difficulty pubsub in SAFENetwork would be implemented) then a subscription for the data update would almost totally cut off possibility for DoS. (The tiny shed of vector left, is requesting data again once the TTL has run out, i.e. the attacker could do a request with TTL frequency. But that would be a very expensive and weak attack…)
Really, this depends.
What serves most is to look at it from a probabilistic viewpoint.
If data in network is requested 10 times in average within a TTL, and an update on the data has been done in average 3 times during the same period, then using pubsub consumes less resources. These are of course just random figures. We don’t know any average numbers (well, maybe someone can dig up some research on it, would be interesting to see), but at least we can say that if NumberOfRequests converge with NumberOfUpdates, then pubsub is not going to give lower load (and not higher either). Whenever NumberOfRequests > NumberOfUpdates, there is a possible gain with pubsub.
Again, all other complexities of its implementation aside.