# Design an Event-Driven CPU Overheat Controller Design an `OverheatPreventionController` that simulates multiple processor cores without physical sensors. Each core has a power load and temperature. Cooling combines one passive capacity shared across the processor with an active capacity assigned per running core. The controller exposes three operations: - initialization with cooling capacities and stable core IDs; - `set_core_load(timestamp, core_id, watts)`, which schedules or applies a load change and may restart a shut-down core; - `tick(timestamp)`, which advances the simulation and returns the IDs of cores whose externally visible state changed since the previous tick. Explain the state model, time advancement, event ordering, shutdown/restart behavior, and tests. Do not guess a particular heat equation or threshold; identify those as requirements that must be clarified. ### Constraints & Assumptions - Timestamps are monotonic but may have gaps of arbitrary length. - Load changes are processed lazily through time advancement rather than a background thread. - A core can be running or shut down, and its temperature and requested load must be tracked. - The result of `tick` must have deterministic ordering. - All state changes at one timestamp must be handled atomically from the caller's perspective. ### Clarifying Questions to Ask - What exact equation converts load, elapsed time, and cooling into temperature change? - How is shared passive cooling divided among running, idle, or already shut-down cores? - What temperature triggers shutdown, and is there a different restart threshold? - Does `set_core_load` take effect before or after thermal evolution at the same timestamp? - Does calling `set_core_load` immediately restart a core, or merely request a restart at the next tick? - Which fields count as a state change returned by `tick`, and should IDs be sorted or event-ordered? ### What a Strong Answer Covers - Per-core state, controller-wide time, pending events, and last-reported snapshots. - One centralized `advance_to(timestamp)` path used by both public operations. - Piecewise simulation across event timestamps rather than applying all elapsed time at the final load. - Explicit same-timestamp precedence and deterministic changed-ID ordering. - Shutdown, cooling while shut down, requested-load retention, and restart transitions. - Validation of unknown IDs, backward timestamps, duplicate operations, and numeric boundaries. ### Follow-up Questions - Can the next threshold crossing be computed analytically instead of stepping through time? - What if several cores shut down simultaneously and thereby change shared cooling allocation? - How would you make repeated calls at the same timestamp idempotent? - Which invariants would you assert after every transition?