I've got a question about how processing/queries are performed in Spice: I've got a schema that pretty heavily relies on a lot of arrow functions which go very, very deep and are incredibly hard to cache (presumably). Is it correct to assume that when evaluating a request; that Spice breaks each individual member of a 'permission' into a problem (or series of problems to solve) and then waits to solve all problems prior to returning a 'true' response? ie: true is not returned after user is found to have access in one 'problem', and then - operators are evaluated to confirm that? Would it also be correct to also assume that if i have a recursive permission computation, and the result of a specific 'problem' (logically) would have been solved by a previous member of the permission - would that result then be recomputed?

SpiceDB does break requests down into subproblems, but they are cached and re-used as much as possible. If two subproblems in the same request are exactly the same, the second subproblem will be cached. That said very wide and/or very deep graphs will have lots and lots of subproblems, so if there are ways to remove hops from your schema you should see some improvements

@ecordell so lets say after traversing the tree; the problem ultimately resolves into fetching 'org:1#members' - that will be cached across the entire request/for the 5s cache interval?

More or less, though the cache key is based on the subproblem input and not the result. Each node in a spicedb cluster is part of a hashring that determines which node owns the cache result for that subproblem. Any future subproblems will go to the owning node, which will have the result in its cache after the first time it gets that subproblem. We have plans for more caching layers as well, but they're not implemented yet.