How Chargify processes OCPP messages, handles failures, and keeps your operations running.
Charger connects via OCPP WebSocket
→Messages processed and validated
→State updated in database
→Events pushed to dashboard in real-time
┌─────────────┐ OCPP 1.6J ┌─────────────────┐
│ Charger │ ◄───WebSocket───► │ ws-engine │
│ (EVSE) │ │ (Go backend) │
└─────────────┘ └────────┬────────┘
│
▼
┌────────────────────────┐
│ PostgreSQL │
│ (Persistent State) │
└────────────┬───────────┘
│
▼
┌────────────────────────┐
│ Redis │
│ (Real-time + Cache) │
└────────────┬───────────┘
│
▼
┌────────────────────────┐
│ Next.js Frontend │
│ (Dashboard + API) │
└────────────────────────┘All state changes flow as events. No polling hacks. StatusNotifications, Heartbeats, and Transactions are processed as they arrive.
Persistent WebSocket connections to chargers. Real-time bidirectional communication as OCPP intended.
PostgreSQL for persistent data. Redis for real-time state and caching. Full audit trail for every message.
Connection drops are expected. Sessions resume cleanly. No data loss on reconnects.
Application servers are stateless. Horizontal scaling without session affinity. State lives in the database.
Runs on managed infrastructure. Automatic TLS. No single points of failure.
No silent failures — every error is logged and classified
Protocol-level visibility — OCPP Log Inspector for debugging
Session recovery — transactions survive reconnects
Idempotent operations — safe to retry on failure
Audit trail — every message and action is recorded
Have technical questions? We're happy to discuss architecture details.
Contact Us