Design Power-Grid Device Monitoring over Unreliable Networks: Dedup and Late Events

Design a monitoring platform for devices deployed across a power grid, such as meters and sensors at substations and along lines. Each device periodically reports measurements (for example power consumption and voltage) and uploads its logs. Devices reach the platform over the **public internet on unreliable networks**: connections drop, messages are retried, and devices can be offline for hours before reconnecting. The design must make ingestion **idempotent**, **deduplicate** repeated data, handle **out-of-order events** correctly, and support **batched log uploads** from devices, while giving operators dashboards and alerts about device and grid health. ```hint Let the device name its data Consider what identifier a device can attach to every reading so that the server can recognize a retransmission no matter how many times, or how late, it arrives. ``` ```hint Two clocks Every event has the time it was measured and the time it arrived, and on this network they can be hours apart; decide which one each computation and alert should use. ``` ### Clarifying Questions - How many devices, how often do they report, and how large are their logs? - How fresh must alerts be, for example for a device reporting a dangerous voltage? - How much can devices store locally while offline, and can their firmware be updated? - Are device clocks synchronized, and how far can they drift? - What are the security requirements: device identity, and protection against spoofed readings? - How long must raw readings and logs be retained? ### What a Strong Answer Covers - Capacity estimates for readings per second and log volume - Device-side design: buffering while offline, batching, retries with backoff, and sequence numbers - An ingestion design that is idempotent and deduplicates at scale, with a clear definition of a duplicate - Event-time processing with late and out-of-order data, and how alerts and aggregates stay correct - Storage for time-series readings compared with bulk logs, and the query and alerting paths - Security of device identity and data, backpressure when many devices reconnect at once, and operational monitoring ### Follow-up Questions - After a regional outage, a million devices reconnect within the same minute. What happens, and how do you prevent it from overwhelming the platform? - A device's clock jumps by a year. How do you detect it and limit the damage? - How would you push configuration or firmware updates to devices safely over the same unreliable network? - Operators need an alert within 30 seconds when a substation's readings exceed a threshold. How does that path differ from the bulk ingestion path?