The Worst Data Platform Ever?

Why It Matters

A flawed data platform threatens reliability, security, and scalability of expanding EV charging networks, directly impacting customer experience and regulatory compliance.

Key Takeaways

• Centralized PostgreSQL creates single point of failure for system
• Direct DB access from apps bypasses service layer security
• VPN tunnel per charger hampers scalability and increases latency
• Mixing operational, analytical, support workloads overloads central database
• No data partitioning prevents performance optimization and regulatory compliance

Summary

The video spotlights a deliberately terrible data architecture built around electric‑vehicle charging stations, using a single PostgreSQL instance as the backbone for every function—from charger telemetry to customer‑facing applications.

By routing each charger through a VPN tunnel straight to the central database, the design creates a massive scalability bottleneck and a single point of failure. Analysts, support staff, and the web and mobile front‑ends all share the same read‑write workload, eroding performance and exposing sensitive data to unnecessary risk.

The presenter calls it “maybe the worst platform use case ever,” noting that the API gateway and web server connect directly to the database without any service layer, and that the VPN‑based connectivity forces every station to depend on the same network path.

Such an architecture would cripple any growing EV network; modern best practices demand decoupled services, event‑driven ingestion, read‑replicas, and strict access controls. Redesigning the platform can lower latency, improve reliability, and meet regulatory data‑handling standards.

Original Description

To learn good platform design you first have to see a really bad one. And this one is exactly that :D

What do you think is wrong with this and how would you fix it?

#dataengineering #dataplatform