Design a Power-Plant System from an Underspecified Prompt

# Design a Power-Plant System from an Underspecified Prompt The preserved report names “power plant” as the system-design topic and says the discussion covered requirements, estimates, architecture, failure handling, APIs, data schemas, distributed jobs, and queue choice. It does not preserve the product's actual users or functions. Begin by defining the intended system with the interviewer. Then present one architecture under clearly labeled assumptions rather than treating telemetry, remote control, or fleet management as source facts. ### Constraints & Assumptions - Only the topic and expected design dimensions above are preserved source facts. - The system might concern monitoring, planning, maintenance, simulation, or another workflow; select none silently. - Capacity, latency, retention, availability, and safety boundaries must be quantified after the function is known. - For an illustrative design, you may assume read-only equipment monitoring plus distributed maintenance-analysis jobs, with no remote equipment actuation. - Under that illustration, define device and collector identity, protected transport, site-scoped operator access, and auditable administrative and data access; these are design choices, not preserved source details. ### Clarifying Questions to Ask - Who uses the system, and what action or decision must it support? - Is one plant or a fleet in scope, and are reads, analytics jobs, or control commands required? - What event rates, retention, freshness, and recovery objectives apply? - Which functions must remain local, and what security or regulatory boundaries exist? ```hint Make the first box a requirement Do not draw a telemetry pipeline or command service until the interviewer confirms that the product actually ingests telemetry or issues commands. ``` ### What a Strong Answer Covers - A disciplined recovery of the missing functional and nonfunctional requirements - Capacity estimates derived from stated variables rather than invented numbers - APIs, schemas, queues, and job semantics tied to the chosen scope - Failure handling, idempotency, concrete security boundaries, observability, and recovery - A clear separation between source facts and illustrative assumptions ### Follow-up Questions 1. How would the architecture change if the intended product scheduled electricity generation rather than maintenance analysis? 2. Which queue guarantee does each job require, and how would duplicate delivery be handled? 3. What evidence would show that a disconnected site has safely caught up?