## Scenario Design a control system that sends commands to large groups of intermittently connected devices. A command might ask every air conditioner in a region to reduce power use by 20 percent. A device may not receive the command, may receive and reject it, may accept it, or may execute it and report telemetry later. The control center must measure command progress from telemetry, reconcile late or missing reports, and use the result when planning later commands. Cover targeting, dispatch, per-device state, retries, idempotency, telemetry ingestion, aggregation, late events, reconciliation, safety, and observability. ### Constraints & Assumptions - A command campaign is immutable and has a unique ID and targeted device-set snapshot. - Delivery acknowledgment, acceptance, execution, and measured effect are distinct states. - Devices and networks are untrusted to be timely, but device identity is authenticated. - A later command must not be overwritten by a delayed earlier one. ### Clarifying Questions to Ask - How many devices, regions, campaigns, and telemetry events are expected? - What deadlines and retry limits apply to a campaign? - Can devices report command ID and monotonic sequence or configuration version? - Is compliance based on explicit execution status, observed power change, or both? - Which safety constraints limit automatic follow-up commands? ```hint Correlate every observation Telemetry needs device ID, command ID or applied version, event time, ingest time, and status. Otherwise a late measurement cannot be assigned safely. ``` ### What a Strong Answer Covers - Immutable campaign definitions, target snapshots, and a detailed device-command state machine. - Partitioned fan-out, durable delivery, device-side idempotency, version fencing, and bounded retries. - Authenticated telemetry, event-time processing, deduplication, watermarks, and revision of progress aggregates. - Reconciliation jobs for unknown states and explicit confidence or denominator semantics. - Human or policy guardrails, audit trails, and metrics for delivery through measured execution. ### Follow-up Questions 1. How do you distinguish a device that rejected a command from one that never received it? 2. What happens when an older command arrives after a newer command was applied? 3. How should progress be reported when a large fraction of devices are offline?