200K+ Authorization Checks per sec with Graph Based RBAC and Zero DB Hits

The Situation & Challenge:

At Blueflite, drone operations platform serves multiple organizations with straightforward roles:

• Operators : Plan and execute operational tasks.
• Maintenance Crew : Manage equipment, records, and servicing.
• Supervisors : Oversee operations, assets, and personnel.

Each role spans multiple functional areas — for example:

• Operations
• Asset Management
• Personnel Management
• Analytics & Reporting

but access isn’t flat. The system naturally has nested structure:

Asset Management → asset records, inventory, maintenance logs

Operations → plans, checklists, data uploads

Personnel Management → profiles, qualifications, schedules

Sounds simple, right? The complexity emerged from two factors:

1. Hierarchical permissions:

Granting Fleet access should imply submodules like Vehicles, but not bleed into unrelated siblings.

• An operator with mission-planning permissions should be able to view and update mission plans and checklists, but not upload post-operation data.
• A supervisor with full asset management rights should have visibility over every sub-area within that module.

2. Multi-Tenant Scoping

1. Org A's pilots shouldn't see Org B's data. Every permission check needs organization-level isolation. Simple & straightforward.
2. Roles are fully customisable, allowing any combination of module and submodule permissions..

2. The Task: Flexible Authorization Without Role Explosion

We needed an authorization system that could:

1. Support hierarchical permissions:
2. course grain: Module-level
3. fine grain: sub-module-level control
4. Handle dynamic reorganization: Product could restructure modules anytime
5. Scale across tenants: Permissions scoped per organization
6. Stay maintainable: Minimal config, no hundreds of manual permission guards

3. The Action: Permission Graphs

Instead of treating permissions as flat strings, we modeled them as a directed graph.

A directed graph mirrors the real domain:

• Nodes are permissions for e.g: module.submodule:action.
• Edges express implication for e.g., delete → update → create → read.
• Module nodes connect to all of their sub‑module nodes.
• Traversal semantics: if there’s a path from a user’s granted node to the required node, access is allowed.

This approach gives us:

• Coarse-grained control – grant access to an entire module.
• Fine-grained control – grant access only to specific submodules or actions.
• No need to duplicate rules or hard-code every relationship — the graph structure defines them automatically.

How the System Works?

System models permissions as a directed graph, by structuring permissions this way:

• Higher-level access naturally cascades to related resources.
• Unrelated areas remain isolated, even within the same module family.
• The relationships are maintained in one place, eliminating duplication and reducing the risk of configuration drift.

Permission from a higher node trickles down to all of its child permissions in the hierarchy.

• Edges = Implications
• delete → update → create → read
• Module-level nodes imply all sub-modules.
• Fine-grained nodes do not imply siblings.

\

This structure naturally supports

1. coarse-grained (module)
2. fine-grained (sub-module) permissions without duplicating rules.

Boot-Time Pre-computation

When the system starts, it plots the entire permission graph from the configuration.

For each permission node, it calculates all reachable nodes by traversing the graph.

We run a transitive closure algorithm like Floyd–Warshall or equivalent to produce a compact reachability map.

• Runtime check = “Does Node A reach Node B?” → a constant-time O(1) set membership lookup.
• No database hits on the hot path roles are resolved once and then checked entirely in memory.

This process is repeated for every node, producing the complete transitive closure.

Runtime flow:

1. Look up user’s granted permission in the map (O(1)).
2. Check if target permission exists in its Set (O(1)).
3. No DB hits checks run entirely in memory.

4. Results & Impact

The graph-based approach delivered measurable improvements across all key metrics:

 Configuration Simplification

1.  From 1,200+ lines to <50 lines of permission configuration
2.  Auto-generated relationships eliminate manual permission mapping
3.  Single source of truth for all hierarchical rules

 Performance Gains

1.  ~0.1ms per authorization check (down from 10-100ms)
2.  200K+ checks/sec capacity on standard hardware
3.  70% reduction in middleware overhead through unified context extraction and caching
4. Zero database hits on the authorization hot path

 Operational Benefits

1.  Custom Roles: Assign any combination of module and sub-module permissions without role explosion
2. Hierarchy Enforcement: Delete permissions automatically imply update, create, and read access
3.  Dynamic Restructuring: Product teams can reorganize modules without breaking existing permissions
4.  Multi-Tenant Isolation: Organization-scoped permissions work seamlessly across all permission levels

 Real-World Flexibility

 The system naturally handles complex scenarios:

1.  An operator with mission:update automatically gets mission.flight_plans:update and mission.flight_plans:read
2.  A supervisor with fleet:delete gains full access to all fleet submodules and their hierarchical permissions
3.  Wildcard permissions like *:read grant read access across every module and submodule in the system

 Scalability Metrics

1.  Memory footprint: <0.1MB for core permission graph
2.  Hardware requirements: Runs efficiently on 4GB+ servers
3.  Cost efficiency: 10x reduction in infrastructure costs compared to traditional RBAC systems

 This architecture proves that enterprise grade authorization doesn't require enterprise-grade infrastructure just thoughtful engineering.

#rbac #engineering #blueflite #authroziation