Design a power grid monitoring and control system

Design a system for monitoring and controlling a power grid. The report gives only this one-line prompt, so settle the scope with the interviewer first. In its usual form, the system collects measurements and equipment status from devices across the grid (substations, breakers, transformers, generation, meters), shows operators the grid's state in near real time, raises alarms, and lets operators send control commands back to equipment. ```hint Up and down are different paths Compare the volume, latency and correctness needs of measurements flowing up from devices with those of commands flowing down to them, and decide whether one pipeline should carry both. ``` ```hint The field is unreliable Links to substations drop, devices buffer data and reconnect later, and clocks drift. Decide what an operator sees, and what the system lets them do, when a device's data is old. ``` ### Constraints and Clarifications - Not given: the number and kinds of devices, measurement rates, latency targets for alarms and commands, how devices connect, and whether any control is automatic. Ask, or state your assumptions. ### Clarifying Questions - Which assets are in scope (transmission substations, distribution feeders, customer meters, solar and batteries), and roughly how many of each? - How often does each kind of device report, and do devices push changes or wait to be polled? - Is control only operator-initiated, or are there automatic actions such as load shedding? What must stay local to the equipment? - How fast must an alarm reach an operator, and a command take effect? - How do devices connect: directly, or through a gateway at each substation, and over which protocols? - Who may issue which commands, and do some require a second person's approval? - How long must history be kept, and what analysis runs on it? ### What a Strong Answer Covers - Scope and estimates: device counts, measurement rates, data volume and command volume - Ingestion through substation gateways into a live state view and a time-series history, with data quality and staleness carried end to end - Alarm processing that copes with floods: deduplication, hysteresis, prioritization and correlation - A safe command path: authorization, interlocks checked against current state, exactly-once execution, confirmation from telemetry, and an audit trail - Failure handling: lost links, buffered data on reconnect, control-center failover, and the grid staying safe when the software is down - Security for critical infrastructure, scaling and observability ### Follow-up Questions - A substation loses its link for ten minutes and then reconnects with buffered data. What happens to the live view, the alarms and the history? - An operator opens a breaker, but no acknowledgement arrives. What does the system do? - How would you add automatic load shedding when demand exceeds supply? - A storm produces thousands of alarms in a few minutes. How do operators find the ones that matter?