CASE STUDY

Prompt Sharing Platform

4 min read·615 words·Intermediate

Asked at

2 candidate reports between Oct 2025 and Jul 2026

How to use this case study

SDE-2 / Mid

Model prompts with immutable versions, sharing permissions (private, specific people, link, public) and a remix (fork) action.

SDE-3 / Senior

Go deeper on the permission model and revocation, attribution chains for remixes, public discovery and search, and safe execution of someone else's prompt.

Staff / Principal

Discuss abuse and moderation, secrets leakage, scale of public discovery, and analytics for creators.


0) Problem Restatement

Design a product where people share AI prompts (asked at Anthropic twice). A user writes a prompt (maybe with variables and settings), then shares it privately, with specific people or their team, via a link, or publicly. Others can view, run (with their own account and credits), or remix (copy and edit, keeping attribution). The owner can revoke access. Shared versions must be stable: if the owner edits later, people who were given version 3 still see version 3 unless they choose to update.


1) Requirements

  • Create prompts with versions (immutable once published).
  • Share settings per prompt: private, specific users or groups (view or edit), anyone with the link, public.
  • Run a shared prompt safely, using the runner's own quota. Never expose the owner's API keys or hidden data.
  • Remix: fork into your own copy with a "remixed from" link.
  • Revoke: links and grants stop working immediately.
  • Discover public prompts: search, tags, popularity.


2) Data Model

CREATE TABLE prompts (prompt_id UUID PRIMARY KEY, owner_id UUID, title TEXT, visibility TEXT,  -- private, link, public
                      latest_version INT, remixed_from_version_id UUID, created_at TIMESTAMP);
CREATE TABLE prompt_versions (version_id UUID PRIMARY KEY, prompt_id UUID, version INT,
                      body TEXT, variables JSONB, model TEXT, params JSONB, published_at TIMESTAMP);
CREATE TABLE prompt_grants (prompt_id UUID, principal_type TEXT, principal_id UUID, role TEXT,  -- viewer, editor
                      PRIMARY KEY (prompt_id, principal_type, principal_id));
CREATE TABLE share_links (token_hash TEXT PRIMARY KEY, prompt_id UUID, version_id UUID NULL,     -- NULL = latest
                      role TEXT, expires_at TIMESTAMP, revoked BOOLEAN);
CREATE TABLE prompt_stats (prompt_id UUID PRIMARY KEY, views BIGINT, runs BIGINT, remixes BIGINT);
  • Versions are immutable, which gives stable sharing and exact reproducibility.
  • A share link can pin a version, or follow the latest.
  • Link tokens are random, and only their hash is stored (like passwords).


3) Architecture

Architecture Diagram

flowchart LR
    U["Users"] --> API["Prompt API"]
    API --> AUTHZ["Permission check"]
    AUTHZ --> DB[("Prompts, versions, grants, links")]
    API --> RUN["Run Service - uses runner's own quota"]
    RUN --> MG["Model Gateway"]
    API --> K[("Events: published, shared, remixed")]
    K --> SRCH["Search index - public prompts"]
    K --> MOD["Moderation"]
    K --> STATS["Stats counters"]
    DISC["Discover page"] --> SRCH

4) Key Flows

  • Open a shared prompt: resolve by grant (user or team) or link token → check it isn't revoked or expired → return the allowed version.
  • Run: the run service loads the version, fills in the runner's variables, and calls the model gateway using the runner's account and limits. The owner's secrets are never part of a prompt; if a prompt needs tools or keys, the runner must connect their own.
  • Remix: copy the version body into a new prompt owned by the remixer, and set remixed_from_version_id. The attribution chain is a linked list you can follow back to the original.
  • Revoke: delete the grant or mark the link revoked. Permission checks happen on every request (with only very short caching), so access ends quickly. Already-made remixes stay with their owners (they're copies), which is a policy to state clearly.
  • Publish publicly: moderation checks first (harmful content, embedded personal data or secrets), then indexing for search.


5) Safety and Abuse

  • Prompt injection from shared prompts: a shared prompt could try to trick tools into leaking the runner's data. Runs of shared prompts get restricted tool permissions by default, and the UI shows what the prompt will access.
  • Secret scanning: detect API keys or passwords pasted into prompt bodies before sharing, and warn or block.
  • Spam in public discovery: rate limits, reputation, reports, moderation.


6) Trade-offs & Alternatives

DecisionChoiceWhyAlternative
VersionsImmutable, pinned by linksStable sharing, reproducible runsEdit in place: shared prompts change unexpectedly
PermissionsGrants + hashed link tokens, checked each requestFast revocationLong-lived cached ACLs: slow revocation
RunningRunner's own quota and credentialsNo cost or secret leakage to the ownerOwner pays: abuse risk
RemixCopy + attribution linkIndependent edits, credit keptShared editable doc: conflicts

7) Wrap-Up

Store prompts with immutable versions, and share them through explicit grants (users or teams, viewer or editor) and hashed, revocable, optionally version-pinned link tokens, checking permissions on every request. Run shared prompts with the runner's own quota and restricted tool access, remix by copying with an attribution chain, and moderate plus secret-scan anything made public before indexing it for discovery.

More Case Studies

Practice with a Mock Interview

Apply what you learned in a live system design mock interview with our AI interviewer.

Start System Design Interview →