Skip to main content

How the Pieces Fit

ALERTCalifornia runs ~1,400 wildfire cameras across the state. This platform is the backend that keeps them capturing, stores what they see, runs AI detection over it, and turns a detection into an alert on the right person's phone. It isn't one program — it's about ten applications that each do one job and coordinate almost entirely through shared state, not direct calls.

The shape of the system​

Nothing here calls the acquisition engine over RPC. Instead, apps write to shared stores (Cosmos, SQL, Table, Blob) and message queues, and other apps react. That decoupling is the platform's defining trait:

The three ideas that recur everywhere​

Read the engine section and you'll meet the patterns the whole platform is built on:

  • Three states per camera — intended config in Cosmos, live runtime in a durable entity, and a monitoring mirror in Table Storage that downstream reads instead of the engine.
  • Coordinate through shared state and queues — the Admin API drives the engine by writing Cosmos; the engine feeds CameraOperation and MetadataCleanup through queues and index tables.
  • The shared Infrastructure package — every app gets its Cosmos/SQL/Blob/Table/Queue repositories, encryption, and communication services from AlertCAInfrastructure, documented in its own section.

The reading path​

The sections build outward from the hard core:

  1. Image Acquisition Engine — the durable orchestration + entity that runs each camera (start here; it's the trickiest and everything else references it).
  2. Camera Communication — how the engine talks to real and simulated cameras.
  3. Inventory & Bootstrap — where camera config and credentials come from.
  4. Camera Operation — the periodic jobs around the engine.
  5. Image Storage & Cleanup — where captured imagery lives and how it's retired.
  6. Admin API — the control plane that drives it all.
  7. Notifications — turning detections and alerts into messages.

Wrapping up​

The ImageAcquisition platform is a set of small, single-purpose apps that coordinate through shared Cosmos/SQL/Table/Blob state and queues rather than direct calls — with a durable-functions engine at the center running ~1,400 cameras. Start where the real complexity is: Two Machines, One Camera.