Resilient Telemetry Platform

Project Summary

A Platform that simulates search and rescue telemetry in realtime. The system is fault tolerant, distributed, secure, deterministicly able to replay scenarios, and involves multiple components acting in unison to achive a reliable picture of the operation. Builds and runs on Windows and Linux

Architecture Overview

Purposeful cross-language boundary: Assigned deterministic scenario generation and fault orchestration to Python, while C++20 owns ingestion, validation, ordering, persistence, projection, replay, and the operations API. Shared Protocol Buffers definitions, canonical hashes, and golden test vectors prevent the two languages from interpreting contracts differently.
Authenticated at-least-once delivery: Placed durable NATS JetStream between simulated units and the backend, with a unique NKey identity and least-privilege subjects for every unit. Deliveries are acknowledged only after PostgreSQL commits, while database uniqueness and canonical payload hashes make redelivery logically idempotent and expose identity collisions.
Immutable history with rebuildable state: Defined the append-only telemetry event log as the source of truth and the latest-unit table as a replaceable projection. Projection precedence uses boot epoch and sequence number so delayed events cannot move state backward, while damaged projections are rebuilt in isolation and promoted only after validation.
Bounded, order-preserving concurrency: Designed a finite input queue and deterministic unit-ID worker sharding so one unit’s events remain ordered while different units process concurrently. Each worker exclusively owns its database connection, and RAII, std::jthread, stop tokens, and explicit backpressure keep overload and shutdown behaviour controlled.
Truthful operator semantics: Separated telemetry freshness from reported equipment health and explicitly modelled CURRENT, STALE, UNKNOWN, PARTIAL, UNAVAILABLE, REBUILDING, and DISCONNECTED states. Operator requests use transactional outbox intent, stable correlation IDs, and a durable lifecycle that cannot report completion without request-specific evidence.
Verification built into the architecture: Designed seeded scenarios, a completed-run barrier, deterministic replay through the production projection logic, canonical checksums, and repeatable fault profiles as first-class components. Requirements and release gates map to retained tests, metrics, logs, sanitizer results, and evidence packages so resilience claims must be demonstrated rather than assumed.

Screenshots

Use the arrows to browse, then select a screenshot to enlarge it.

No screenshots have been added.