An Energy Operator's Data Platform, Built for Real-Time and Scale
Client
Co4 Cloud
Sector
Energy and utilities
Geography
Liechtenstein, Europe
Engagement type
Build, greenfield production system
Practice lines
BI and analytics modernization, cloud, data platform engineering
Status
Completed
- A multi-resource energy operator needed real-time monitoring and multi-tenant oversight across gas, electricity, EV charging, and carbon emissions in one platform.
- We shipped a microservices backend behind a Piral microfrontend shell, with sensor data flowing through a FastAPI ingestion service into PostgreSQL and GraphQL-backed operational views.
- Role-based access is enforced at the API layer for owners, managers, customers, technicians, and operators.
- The result is a modular platform that supports self-service multi-tenant onboarding and a clear path for new resource types and partner applications.
Problem
Co4 Cloud needed a production-grade web platform for gas, electricity, EV charging, carbon emissions, billing, and multi-tenant resource oversight. Data lived across sensor networks, metering systems, and reporting tools. Adding new facilities, occupants, or resource types required engineering work instead of controlled configuration.
Constraints
The platform had to serve distinct user populations - owners, managers, customers, technicians, and operators - each with different access. It had to ingest sensor data at sensor rate without losing real-time fidelity, and it had to let the operator onboard new tenants and resource types without a development cycle for each addition.
What ViitorCloud shipped
We built a centralized energy management portal on a microservices backend and a Piral microfrontend shell. Sensor data flows through a FastAPI ingestion service into PostgreSQL and GraphQL-backed operational views. Role-based access is enforced at the API layer across all five user populations.
Architecture and delivery approach
A microservices backend separates ingestion, operational data, and tenant management so each can scale and evolve independently. The Piral microfrontend shell lets new modules and partner applications plug into the portal without rebuilding it. FastAPI handles ingestion; PostgreSQL holds operational state; GraphQL serves the operational views the portal renders. Access control sits at the API layer, not the UI, so permissions hold regardless of client.
Outcome
The platform now centralizes resource management, supports real-time monitoring at sensor rate, enables self-service multi-tenant onboarding, and gives the operator a modular path for new resource types and partner applications.
What buyers should learn
A real-time multi-tenant platform is an architecture decision before it is a feature decision. Choosing microservices plus a microfrontend shell up front is what makes self-service onboarding and new resource types a configuration task later, rather than an engineering project each time. Enforcing access at the API layer is what keeps a multi-population platform defensible as it grows.
- Analytics Modernization
BI and analytics modernization for real-time operational data.
- Cloud FinOps
Keeping a real-time, multi-tenant cloud estate cost-efficient as it scales.
- AI Workflow Automation
Automating operational workflows on top of a centralized data platform.
- Cloud FinOps 90-Day Runbook
Playbook
- KPMG Welfare Beneficiary Database
Case Study
- Decentralized Credential-Sharing Platform
Case Study
Building a Real-Time, Multi-Tenant Platform?
Book a 30-minute scoping call. We will talk through the architecture decisions that keep a real-time platform modular and self-service as it grows.