Deep Dive: Our Real-time Telemetry Architecture

Building a platform that can ingest thousands of data points per second from a rapidly growing fleet of electric vehicles is no small feat. In this post, we peel back the curtain on the TesDash telemetry pipeline and how we moved from a traditional containerized stack to a cutting-edge, serverless "Edge" architecture.

The Shift: From Containers to "Pure Edge"

Traditionally, handling Tesla's telemetry required running heavy, long-lived server processes to manage the complex, secure connections with each vehicle. While effective, this approach struggles to scale instantly when thousands of commuters start driving at 8:00 AM.

We took a different approach. We reverse-engineered the ingestion process to run entirely on Cloudflare Workers. By moving the logic to the "Edge"—physically closer to the cars—we achieved a system with zero cold starts, infinite scalability, and significantly lower latency.

1. The Ingestion Layer: Speed is Safety

The most critical part of the pipeline is the initial handshake. When a car sends data, it expects a rapid response; if the server is too slow, the vehicle assumes the connection is dead and disconnects.

• Immediate Acknowledgement: Our ingestion workers are designed for one thing: speed. Upon receiving a data packet, we instantly validate it and send an acknowledgment (ACK) back to the vehicle. This keeps the connection healthy and prevents the "retry storms" that plague slower systems.
• Zero-Latency Handoff: Once the data is safe, we don't process it there. We hand the encrypted payload off to our processing layer using high-speed internal Remote Procedure Calls (RPCs). This decoupling ensures that complex processing logic never slows down the ingestion stream.

2. The Processing Brain: Serverless Decoding

The industry standard often relies on pre-compiled binaries to decode the complex Protocol Buffers (Protobuf) used by the vehicles. This usually ties you to specific server operating systems.

We built a proprietary Edge-Native Decoding Engine:

• Native Execution: Instead of relying on external binaries, our decoding logic runs natively in JavaScript within the worker environment. This allows us to parse the intricate telemetry stream in milliseconds, directly in memory.
• Real-Time Context: As data streams in, we don't just save it; we analyze it. Our system maintains a live context for every vehicle without needing to query a slow database for every single signal.

3. Asynchronous Persistence: Reliability at Scale

Real-time dashboards are great, but historical data is priceless. To ensure we never lose a signal—even if our database is undergoing maintenance—we treat storage as an asynchronous background task.

• The Queue: Processed data isn't written to the database immediately. Instead, it is pushed into a high-throughput priority queue. This acts as a shock absorber, smoothing out traffic spikes during rush hour.
• Dual-Write Strategy: A dedicated consumer service pulls from this queue and intelligently routes data:
  • Hot Path: Current vehicle status is pushed to a high-speed key-value store for immediate access by the mobile app.
  • Cold Path: Historical time-series data is batched and written to our analytics database (TimescaleDB) for long-term reporting.

Why This Architecture Wins

By moving to this proprietary Edge architecture, we solved the three biggest challenges in fleet telemetry:

1. Reliability: Decoupling ingestion from processing means a database slowdown never disconnects a car.
2. Latency: Processing data at the edge, close to the user, makes the dashboard feel instantaneous.
3. Cost & Scale: We don't pay for idle servers. Our infrastructure scales up when you drive and scales to zero when you park.