Real-Time Transit Telemetry Dashboard System Design

Back to Portfolio

Scaling & Messaging Systems

Developed a live transit telemetry dashboard for visualizing operational signals and route-level movement patterns.

Live Dashboard | Real-Time Signal View

Live DemoSource RepositoryRead Production Upgrade Log

Why This Project Matters

Demonstrates real-time data engineering, stream correctness, and observability-first operations reporting.

Tech + Architecture Summary

  • Tech: Dashboard, Telemetry, JavaScript, AWS S3, Data Visualization
  • Architecture: Transit data feeds -> telemetry processor -> event store -> live dashboard + websocket broadcaster + alert hooks.

Impact Metrics

  • WebSocket telemetry updates delivered route refreshes in ~1 second windows under normal load.
  • Idempotency + late-event correction eliminated duplicate state writes in replay testing.
  • Adaptive backpressure controls stabilized ingestion during synthetic burst scenarios.

Core Problem

Present real-time transit telemetry in a way that is both operationally useful and easy to interpret under fast-changing conditions.

Build Notes

What I Owned

This project helped me practice turning changing backend state into a dashboard that a reviewer can understand quickly without reading the source first.

Hard Lesson

The hard part was deciding what to show and what to hide, because real-time systems can become noisy if every event is treated as equally important.

Next Enhancement

Next I would add replay controls and a short incident timeline so the dashboard can demonstrate late-event correction and backpressure behavior more clearly.

High-Level Architecture

mermaid
graph TD
  Feeds[Transit Data Feeds]-->Processor[Telemetry Processor]
  Processor-->Store[(Telemetry Store)]
  Store-->Dashboard[Web Dashboard]
  Dashboard-->User[Operations Viewer]

Production-Grade Capabilities

  • Event-time ordering + idempotency dedupe for resilient streaming semantics.
  • Adaptive backpressure and queue buffering for burst handling stability.
  • WebSocket-based low-latency telemetry push with operational observability hooks.

Engineering Decisions

  • High-frequency refresh improves recency but increases client render load on lower-end devices.
  • Aggregated telemetry views improve readability, but can hide short-lived outlier events.

Behavioral + Impact Signals

  • Implemented reliability controls before adding feature complexity.
  • Documented stream-processing tradeoffs around freshness and consistency.
  • Built public observability signals for operational credibility.

Quality Guarantees

  • Dashboard updates reflect the most recent available telemetry window.
  • Displayed route/vehicle states remain tied to timestamped source events.
  • Core dashboard views remain accessible without backend control-plane access.

Recent Upgrades

  • Added event-time ordering, idempotency dedupe, and late-arrival correction for robust stream semantics.
  • Introduced adaptive backpressure controls and streaming analytics signal generation for high-throughput conditions.
  • Expanded operations readiness with CloudWatch alarms/dashboard integration and real-time WebSocket push.
  • Added cross-project architecture framing so the dashboard reads as telemetry infrastructure rather than only a visualization project.

Outcome Highlights

  • Deployed a public telemetry dashboard for live viewing.
  • Structured operational data for fast visual interpretation.
  • Focused on usability for real-time monitoring scenarios.