[HN Gopher] Taming P99s in OpenFGA: How we built a self-tuning s...
       ___________________________________________________________________
        
       Taming P99s in OpenFGA: How we built a self-tuning strategy planner
        
       Author : elbuo
       Score  : 15 points
       Date   : 2026-01-22 20:10 UTC (4 days ago)
        
 (HTM) web link (auth0.com)
 (TXT) w3m dump (auth0.com)
        
       | shoo wrote:
       | Fun to see a write up applying multi-armed bandits.
       | 
       | I had a bit of trouble following the article as I don't
       | understand the problem space well enough. When framing this
       | problem, the authors wrote:                 Answering "Can user X
       | access resource Y?" requires traversing relationship graphs. In
       | this context, traversal performance isn't just a feature; it is
       | the fundamental constraint of the system's architecture.
       | 
       | Concretely, in an OpenFGA / Auth0 FGA deployment where graph
       | traversal becomes enough of a bottleneck that introducing a
       | planner like this becomes compelling, how is the graph and the
       | traversal manifested? What's actually going on?
       | 
       | Would the relationship graph be represented as a bunch of
       | relations stored in a single SQL DB? Or does querying and
       | traversing the graph require making a bunch of API calls to
       | various downstream services over the customer's network?
        
         | yehia2amer wrote:
         | 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).
        
       | yehia2amer wrote:
       | I really respect OpenFGA & team behind it, I used it in multiple
       | projects and it completely eliminate the AuthZ from our code.
       | 
       | But it always had this issue with Admin management, It is hard
       | for Admins to understand and maintain.
       | 
       | That's why I created an Admin UI for OpenFGA, The main goal is
       | that the UI is Dynamic and it changes as per your OpenFGA Model,
       | Then you can Easily Add users
       | 
       | I built this because my team was constantly struggling with
       | managing permissions in our applications. we tried building admin
       | UIs multiple times, but every time the OpenFGA model changed, we
       | had to rework the UI layer to match it one way or another.
       | 
       | So mainly the UI understand your OpenFGA schema and automatically
       | renders the management interface based on the entities and
       | relationships defined in your model.
       | 
       | https://github.com/yehia2amer/OpenFGA-Admin-UI
        
       ___________________________________________________________________
       (page generated 2026-01-26 23:01 UTC)