Skip to content
All work

Enterprise / Cloud / AI

Vertiv One Cloud

Multi-tenant infrastructure cloud with an AI-queryable asset graph

Organisation
Vertiv
Role
Backend & full-stack engineering
Period
2024 – Present

Enterprise work — visuals abstracted and details generalised for confidentiality.

Context

What the system is

A multi-tenant platform where each customer organisation manages its own sites, assets, components, gateways and contacts. Everything is relational, deeply nested, and read far more often than it is written.

Vertiv One Cloud centralises management of connected infrastructure across many customer organisations. I work across its backend services, data model and API surface, including the GraphQL layer that lets an assistant answer natural-language questions about assets and their relationships.

Problem

What needed solving

Operator and integration workflows needed data spanning several entity types at once. Fetching it over discrete REST endpoints meant multiple round trips, over-fetching, and client-side stitching — and none of that shape was usable by an AI assistant asking open questions about infrastructure.

  • Strict tenant isolation on every read and write path
  • Role-based authorisation enforced consistently across REST and GraphQL
  • Existing REST consumers could not be broken
  • Long-running operations must not block request latency

Architecture

How it's structured

  • 01

    NestJS 10 services with controllers, services and repositories, wired through dependency injection and explicit module boundaries

  • 02

    PostgreSQL via TypeORM — one-to-many and many-to-many relationships, junction tables, composite indexes and versioned migrations

  • 03

    Dual API surface: documented REST (Swagger / OpenAPI) alongside Apollo Server 4 GraphQL with DataLoader and per-request caching

  • 04

    ArangoDB for connected-infrastructure traversal, accessed behind a repository abstraction

  • 05

    Background workers for long-running data operations so request paths stay fast

  • 06

    Runs on AWS — EC2 for services, RDS for PostgreSQL, S3 for document storage

Platform stack

  • InterfaceNext.js · React · Angular
  • APIREST / OpenAPI · GraphQL / Apollo 4
  • ServicesNestJS 10 · Java / JAX-RS · Background workers
  • DataPostgreSQL · ArangoDB · Oracle
  • CloudAWS EC2 / RDS / S3 · Docker

AI path

  • 01

    AI assistant

  • 02

    LLM query layer

  • 03

    GraphQL asset graph

Natural-language questions resolve into structured infrastructure queries through an introspectable schema.

Asset hierarchy — traversal model

  1. Customer

    tenant

  2. Site

    location

  3. Asset

    equipment

  4. Component

    sub-part

  5. Gateway

    edge

Multi-hop questions across this hierarchy are expressed as graph traversals in AQL rather than recursive SQL — and the same shape is what an assistant queries through GraphQL.

Approach

What I worked on

Modular backend services

Features are built as NestJS modules with explicit service boundaries and injected dependencies, so an entity's rules live in one place rather than spread across controllers.

Repositories sit between services and persistence, which is what made adding a graph store later a contained change rather than a rewrite.

Relational modelling in PostgreSQL

Customers, locations, assets, components, gateways and contacts are modelled relationally with junction tables for the many-to-many paths.

Migrations are versioned and re-runnable; composite indexes were added against the real query shapes rather than speculatively.

REST and GraphQL together

REST stays the documented, stable contract for existing integrations. GraphQL was added for the multi-entity read workflows where the client knows exactly which fields it needs.

DataLoader batches the relationship fetches that would otherwise fan out per-row, with caching scoped to the request.

An API surface an assistant can use

I worked on the LLM-facing query layer: schemas structured for machine consumption, introspectable types, predictable resolver shapes and structured responses.

The assistant translates a natural-language question into a structured infrastructure query. The engineering work is the schema and resolver design that makes those answers reliable — not model training.

Graph traversal with ArangoDB

Connected infrastructure is naturally a graph. Multi-hop hierarchy questions — what sits under this site, what does this gateway reach — are expressed in AQL rather than recursive SQL.

ArangoDB is used as both document and graph store, behind the same repository abstraction as the relational data.

Oracle → PostgreSQL migration

Core entities were migrated from Oracle to PostgreSQL using re-runnable scripts, with referential-integrity validation and reconciliation between source and target.

Verification passes compared record counts and relationships rather than assuming a clean run.

Outcome

What changed

  • A representative multi-entity workflow went from roughly six REST round trips to a single GraphQL query
  • Approximately 40% smaller average payload in that context through precise field selection
  • Local environment setup dropped from around two hours to under fifteen minutes after containerising services and databases
  • Infrastructure data became queryable in natural language through a structured, introspectable API layer

Learnings

What I took from it

Adding GraphQL next to REST works when each has a clear job. The harder and more valuable work was the data modelling underneath — an assistant is only as reliable as the schema it reads.

Next

Enterprise / Monitoring

Vertiv Critical Insight

Alarm workflows, point data visualisation and statistics configuration inside a long-running enterprise monitoring platform.

Founder / Product

VRRentals.in

Started as one headset rented out. Became a multi-device immersive technology operation — and a booking product I built and run.