Telemetry Event Lifecycle — Ingest, Idempotency, Alerts and Dead Letters

Telemetry Event Lifecycle — Ingest, Idempotency, Alerts and Dead Letters A sequence diagram generated by Archify. POST /api/v1/telemetry/simulate?profile=high publish adapter.telemetry.v1 · keyed by adapterId 200 accepted + counts consume adapter.telemetry.v1 INSERT telemetry_event (event_id PK) DuplicateKeyException → Result.Err On a replay the use case stops here: debug log plus tap.onDuplicate, no health write. MERGE adapter_health (new event only) AlertEvent → adapter.alerts.v1 on the 3rd consecutive DOWN malformed JSON · retries exhausted → …v1.dlt DltObserver counts it with a readable reason SSE frames + heartbeat (same origin) Ingest Idempotency and health Alerts, DLT and live view Dashboard · demo control + live view · Sequence participant Dashboard demo control + live view adapter-gateway · REST ingest :8081 · Sequence participant adapter-gateway REST ingest :8081 Kafka · topics + DLT · Sequence participant Kafka topics + DLT telemetry-hub · consumer + read API · Sequence participant telemetry-hub consumer + read API Oracle Free · TELEMETRY_EVENT · ADAPTER_HEALTH · Sequence participant Oracle Free TELEMETRY_EVENT · ADAPTER_HEALTH Legend request return async trace

Idempotency

  • • The Oracle primary key is the referee
  • • A replay is an expected Result.Err, not an exception

Domain decisions

  • • AdapterHealth.observe returns the next state plus an optional alert
  • • Alert ids derive from the trigger event

Failure and live view

  • • Malformed JSON fails deserialization; two retries then the DLT
  • • DltObserver counts it; the SSE tap feeds the dashboard