Design an Interactive Query Execution Notebook

# Design an Interactive Query Execution Notebook Design a notebook-like service in which users submit SQL queries and receive results, similar to an online execution platform. Focus on how the client learns job status and obtains results when execution may outlive the original request or produce more data than one response should carry. ### Constraints & Assumptions - Query execution is isolated from the web tier. - Results may be small enough to preview or large enough to require paged or object-backed delivery. - A user must not read another user's query or result. ### Clarifying Questions to Ask - Which database engines and query time limits are supported? - Must notebooks preserve reproducible cell state or only independent query jobs? - What result size, concurrency, and freshness targets matter? ```hint Treat execution as a job Separate accepting a query from running it and from serving its result pages. ``` ### What a Strong Answer Covers - APIs and state transitions for submission, cancellation, status, and results. - Queueing, worker isolation, credentials, limits, and idempotency. - Polling, server-sent events, or WebSocket trade-offs for status delivery. - Result storage, pagination, expiry, authorization, and observability. ### Follow-up Questions - How would you prevent one expensive query from starving other users? - How would reconnecting clients resume a partially viewed result?