Design an LLM Prompt Playground: Schema, Large Prompts, Sharing and Tiny Edits

Design a prompt playground: a web application where users write prompts for a large language model (LLM), run them against a model, and see the output. Users can save their prompts, come back to them later, and share them with other people. Start with the core design and the database schema. The interviewer then works through a sequence of follow-ups (large prompts, sharing, and tiny edits to large prompts) and moves to the next one once the current one is answered, so keep each answer focused. ### Constraints and Clarifications - Prompts can be large. - A user may edit a large prompt again and again, changing only one or two characters each time. The storage design must handle this without wasting space. - No user counts, prompt sizes or traffic numbers were given. Ask, or state your assumptions. ### Clarifying Questions - What does a saved prompt contain: a single block of text, or system and user messages plus the chosen model and its parameters? - How large can a prompt get, and is there a hard upper limit? - Must every saved version be kept and retrievable, or only the latest version plus explicit checkpoints? - Must every run be reproducible later, with the exact text and settings it used? - Who can see a shared prompt: anyone with a link, or named users only? Can they edit it, or only view and copy it? ### Part 1 — Core design and schema Describe the main components and the APIs for creating, editing, saving, listing and running prompts, then write the database schema. ```hint Separate what users edit from what they ran A prompt keeps changing, but each run used one particular state of it. Decide which entities you need so that any past run can be traced to the exact text and settings it used. ``` #### What This Part Should Cover - Entities and relationships: users, prompts, saved versions, runs and their outputs - APIs for the main operations, and which screens read which data - The run path: calling the model, streaming the output, storing the result - Keys and indexes that serve the common queries ### Part 2 — Large prompts Some prompts are very large. How does your design store and serve them? ```hint Not every byte belongs in the row Consider what large values cost a relational database, and what the list, load and run paths actually need to read. ``` #### What This Part Should Cover - Where prompt bodies live (database or object storage), and the rule for choosing - Which metadata stays in the database, and how integrity is checked - Upload and download paths, size limits and compression - Effects on save, load and run latency ### Part 3 — Sharing Add the ability for a user to share a prompt with others. ```hint Decide what a share points at A shared link can point at a fixed state of the prompt or at whatever the owner saves next. Each choice changes permissions, caching and what recipients see after the owner edits. ``` #### What This Part Should Cover - Sharing semantics: fixed snapshot versus live view, and view versus copy or edit rights - The data model for shares and the access check on every read - Revocation, expiry, and deletion of a shared prompt - Copying a shared prompt without duplicating its storage ### Part 4 — Tiny edits to a large prompt A user edits a large prompt again and again, each time adding only one or two characters, and saves after each edit. How should storage handle this? If you store only what changed, where do those changes live: in the database or in object storage? Present the options and their trade-offs. ```hint Cheap writes, bounded reads Storing only the change makes each save cheap. Think about what that does to loading an old version, and how to put an upper bound on that cost. ``` #### Clarifying Questions for this Part - Which versions are read most often: only the latest, or arbitrary old ones, for example to reproduce a past run? - May old versions be compacted or expired, or must every one be kept forever? #### What This Part Should Cover - Full copies versus storing only changes, with write, read and storage costs compared - Where the changes and the full copies are stored, and why - Bounding the cost of rebuilding any version - Correctness when two saves of the same prompt race ### What a Strong Answer Covers - A schema in which every run can be reproduced from stored data - Storage placement decisions backed by size and access-pattern reasoning - A change-based versioning design with bounded read cost and a compaction story - Sharing semantics stated before mechanics, with safe access control - Focused answers that keep pace with a quick sequence of follow-ups ### Follow-up Questions - Two browser tabs save the same prompt at the same moment. What happens? - An owner deletes a prompt that others have copied or have open through a share. What do they see, and what is actually removed from storage? - How would you show a diff between any two versions? - Many users copy the same popular shared prompt and make small changes to it. Can storage take advantage of that?