# Design a Prompt Playground The source reports a full-stack Prompt Playground system-design interview covering product features, UI, architecture, and scale, with each run independent rather than part of a chat. The concrete reliability and data-handling requirements below are practice scope, not additional reported interview facts. Design a web platform where a user edits a prompt template, supplies variables, chooses a model and generation settings, executes an independent run, and inspects or compares outputs. Do not design conversational history: every run is a separate experiment with an explicit input snapshot. Cover the editor and results experience, prompt drafts and immutable versions, run API, execution workers, streaming, provider adapters, persistence, cancellation, quotas, and observability. Explain how a saved result retains its meaning when a prompt draft, model default, or provider API later changes. ### Constraints & Assumptions - Model calls can be slow, fail after acceptance, stream partial output, and incur variable cost. - Prompts may contain variables and private test inputs. - A run records the exact resolved prompt, model identifier, provider, parameters, and input used. - Interactive runs should not be starved by larger evaluation batches. - Provider credentials stay server-side, and one workspace must not access another workspace's prompts or outputs. ### Clarifying Questions to Ask - Which providers, models, and modalities are required? - Which editor features matter first: variables, side-by-side comparison, batch inputs, or automatic evaluation? - What latency, retention, cancellation, and budget expectations apply? - Must partial output survive a client disconnect? - Which run metadata is required for reproducibility and audit? ### What a Strong Answer Covers - A coherent user flow and component boundary from editor through execution and results. - Immutable run provenance with a clear transactional data model. - Durable asynchronous state, streaming, idempotency, cancellation, and provider-failure handling. - Tenant isolation, secret handling, quota enforcement, cost accounting, and useful observability. - Explicit trade-offs between interactive latency, batch throughput, storage cost, and reproducibility. ### Follow-up Questions 1. How would you compare two prompt versions over a private evaluation set? 2. What happens when the browser disconnects halfway through a streamed run? 3. How would you keep interactive traffic responsive during a large batch? 4. Which requests, if any, are safe to cache?