# Design Real-Time Electricity Monitoring and Policy Control Design a system that continuously receives electricity-usage readings from many devices, monitors consumption in near real time, and changes device usage policies based on the observed load. A policy may reduce, defer, or restore a device's permitted usage. Your design must avoid unsafe oscillation or issuing stale control decisions. Define the functional contract and reasonable scale assumptions before presenting the architecture. Cover telemetry ingestion, stream processing, current and historical state, policy evaluation, command delivery, failure recovery, and observability. ### Clarifying Questions to Ask - How many devices report, how often do they report, and what decision latency is required? - Are control policies per device, per site, or based on aggregate load across a fleet? - Which devices may be controlled automatically, and what safety or manual-override rules apply? - How should late, duplicated, or missing readings affect a decision? ### What a Strong Answer Covers - A versioned telemetry event and device identity model with authenticated ingestion. - Partitioning and windowed aggregation that preserve per-device ordering where required. - A policy engine with explicit thresholds, hysteresis, cooldowns, and auditable versions. - Idempotent, expiring commands with acknowledgement and device-state reconciliation. - Handling for late events, disconnected devices, retries, regional failure, and overload. - Metrics that distinguish ingestion health, decision quality, and command effectiveness. ### Follow-up Questions - How would you prevent a threshold policy from rapidly alternating between reduce and restore? - What happens when telemetry is healthy but command acknowledgements stop arriving? - How would you replay historical readings against a new policy without controlling live devices?