Telematics EventBridge Path¶

This note captures the intended scheduled polling path after the ownership change:

• bf-manage-core owns EventBridge-triggered scheduling.
• bf-manage-core owns scheduled provider polling tasks.
• bf-telematics owns websocket runtime only.
• Scheduled poll results and websocket-originated updates both land in the same core ingest/command handler.

TLDR¶

EventBridge
  -> bf-manage-core scheduled event processor
  -> bf-manage-core workspace poll runner
  -> bf-manage-core provider polling tasks
  -> canonical update payload
  -> shared core ingest / command handler
  -> validation against shared workspace state
  -> snapshot + event history persistence
  -> read APIs / health queries

Main Design Intent¶

• The scheduled poll path must not call bf-telematics.
• Core should load workspace policy, cutover state, and device/provider registry data from shared SQL before running a poll cycle.
• Provider poll responses should be normalized into the same canonical payload shape used by websocket ingress.
• Core should apply one acceptance flow for both sources so validation, rejection, event history, and snapshot updates remain consistent.

Diagram¶

flowchart TD
  subgraph AWS["AWS / orchestration"]
    EB["EventBridge schedule"]
  end

  subgraph CORE_RUNTIME["bf-manage-core poll runtime"]
    SE["scheduled_events processor"]
    RUN["workspace poll runner"]
    STATE["load workspace policy<br/>cutover + device registry<br/>from shared SQL"]
    TASKS["provider polling tasks<br/>inside core"]
    EXT["provider HTTP APIs"]
    NORM["normalize provider response<br/>into canonical updates"]
  end

  subgraph TELEMATICS["bf-telematics websocket runtime"]
    WS["websocket connection manager"]
    WSN["normalize websocket message<br/>into same payload shape"]
  end

  subgraph CORE_CMD["bf-manage-core shared command path"]
    INGEST["shared core ingest / command handler"]
    VALIDATE["validate workspace/device identity<br/>against shared state"]
    UOW["unit of work"]
    SNAP["canonical snapshot store"]
    HIST["event history / event store"]
    OUT["read APIs / health queries"]
  end

  NOHOP["no scheduled poll hop<br/>through bf-telematics"]

  EB --> SE
  SE --> RUN
  RUN --> STATE
  RUN --> TASKS
  TASKS --> EXT
  EXT --> NORM
  STATE --> NORM
  NORM --> INGEST

  WS -. stream path only .-> WSN
  WSN -. same canonical payload .-> INGEST

  SE -. ownership note .-> NOHOP

  INGEST --> VALIDATE
  VALIDATE --> UOW
  UOW --> SNAP
  UOW --> HIST
  SNAP --> OUT
  HIST --> OUT

Step-By-Step Flow¶

1. EventBridge triggers the recurring workspace poll event.
2. bf-manage-core scheduled event processing resolves the target workspace poll.
3. Core loads workspace telematics policy, cutover state, and configured device/provider data from shared persistence.
4. Core runs the appropriate provider polling task inside bf-manage-core.
5. Provider responses are normalized into canonical telematics update payloads.
6. Those payloads are submitted to the shared core ingest/command handler.
7. Core validates workspace/device identity and applies the update transaction through the unit of work.
8. Core persists canonical snapshot state and accepted update history.
9. Read APIs and health queries use that persisted state as the source of truth.

Websocket Relationship¶

• bf-telematics still owns long-lived websocket connections and stream-specific buffering/coalescing.
• Websocket-originated updates should be normalized into the same canonical payload shape as scheduled poll results.
• After that normalization step, websocket updates should enter the same core ingest/command handler as EventBridge-triggered poll results.

Boundary Rules¶

• bf-manage-core is the owner of scheduled polling runtime.
• bf-telematics is not part of the scheduled poll execution path.
• bf-telematics remains an ingress adapter for websocket traffic.
• The shared core ingest handler is the single acceptance point for canonical telematics updates.

Why This Shape¶

• It keeps EventBridge ownership and poll execution in the same service.
• It removes an unnecessary cross-service hop for scheduled polling.
• It prevents drift between websocket handling and scheduled poll handling.
• It makes validation and persistence rules easier to keep consistent.