/* voltgrid */ → architecture

VoltGrid Architektur

Das System hinter der Plattform: Ladesäulen melden über OCPP/MQTT an ein IoT-Gateway, der Realtime-Hub pusht Status live in Apps, Sessions laufen asynchron über Queues in die Abrechnung. Hover über die Knoten zeigt die Datenflüsse.

~/voltgrid · systemarchitektur// hover über die knoten
Fahrer-Appmap · laden · abrechnungBetreiber-Dashboardmulti-tenant · kpisAPI-ClusterREST · auth · rate-limitssessions · tarife · roamingRealtime-Hubwebsockets · status-pushPostgreSQLstammdaten · sessionsTimescaleDBtelemetrie · kW-kurvenQueueredis · eventsBilling-Workersessions → rechnungenIoT-GatewayOCPP · MQTT · ingestLadesäulen ×2.418hardware · telemetriePSPpayments · extern
synchron (request/response) asynchron (queue/events) echtzeit extern / hardware

Zwei getrennte Pfade halten das System ruhig: Der synchrone Pfad (App → API → PostgreSQL) beantwortet Anfragen sofort, der asynchrone Pfad (Queue → Billing-Worker) verarbeitet Session-Abschlüsse und Rechnungen, ohne die API zu blockieren. Telemetrie fließt getrennt in TimescaleDB, 2.418 Säulen senden kW-Kurven, die niemals die Session-Datenbank belasten. Zahlungsdaten bleiben beim externen PSP.

~/voltgrid · eine lade-session, ende zu ende
POST /sessionsapp → api · 201Säule startetapi → gateway → OCPPLive-TelemetriekW-kurve → app · pushSession-Endeevent → queue → workerRechnungpsp · pdf

Der Weg einer Session durchs System: Die App startet per REST, das Gateway weckt die Säule über OCPP, die kW-Kurve kommt live per WebSocket zurück in die App, und nach dem Abstecken wird asynchron abgerechnet. Genau dieser Flow steckt auch hinter dem POST /api/v1/sessions in der Sandbox-API.