Google's Zanzibar actually does both: for the vast majority of queries, it uses significant levels of caching and a permitted amount of staleness [1], allowing Spanner to return a (somewhat stale) copy of the relationship data from local nodes, rather than having to wait or coordinate with the other nodes.
However, some deeply recursive or wide relations can still be slow, so Zanzibar also has a pre-computation cache called Leopard that is used for a very specific subset of these relations [2]. For SpiceDB, we called our version of this cache Materialize and it is designed expressly for handling "Enterprise" levels of scale in a similar fashion, as sometimes it is simply too slow to walk these deep graphs in real-time.
Ooh, and back when that was not a thing (iirc a few years back) me and a friend of mine had built a spiritually similar index for spicedb for our final year project at uni. We had a mini WAL and the ability to safely reject queries that specified a minimum update requirement after the index updation.
However, some deeply recursive or wide relations can still be slow, so Zanzibar also has a pre-computation cache called Leopard that is used for a very specific subset of these relations [2]. For SpiceDB, we called our version of this cache Materialize and it is designed expressly for handling "Enterprise" levels of scale in a similar fashion, as sometimes it is simply too slow to walk these deep graphs in real-time.
[1]: https://zanzibar.tech/24uQOiQnVi:1T:4S [2]: https://zanzibar.tech/21tieegnDR:0.H1AowI3SG:2O