In OpenFGA/Auth0 FGA, the “relationship graph” is not usually a separate graph database or a pile of downstream service calls. It’s an implicit graph whose edges are the relationship tuples you’ve stored, interpreted through the authorization model (the DSL that says how one relation implies another, how to follow parents, groups, etc.).

What the graph “is” in a typical deployment

Edges = tuples like: document:1#viewer@user:anne document:1#viewer@group:eng#member document:1#parent@folder:A

These are persisted in the OpenFGA datastore (commonly Postgres).

What “traversal” actually does at runtime

A Check(user=X, relation=R, object=Y) request is evaluated by resolving the model for (Y#R) and reading whatever tuples are needed to prove/disprove membership.

Traversal becomes painful when checks cause High fan-out (e.g., a document inherits viewers from a folder, that folder has 50 groups, each group contains groups…) or like Deep nesting (group-of-group chains)

That’s exactly the niche where smarter planning/strategy selection helps.

Do checks require “a bunch of API calls to downstream services”?

Normally, no. OpenFGA/Auth0 FGA doesn’t need to call your microservices to traverse your domain graph. The check is decided from: - the authorization model, and - tuples in the OpenFGA store, - plus any contextual tuples you included in the request (ephemeral edges that behave as-if written, but aren’t persisted).