Design Text-to-Image Generation
Design a text-to-image system like DALL-E: diffusion models, prompt understanding, and image generation at scale.
What is a text-to-image generation system?
A text-to-image generation system turns a written prompt into a new image. The model is only one part of the product: the service must understand the request, enforce policy, schedule expensive accelerator work, generate and inspect the image, attach provenance, and deliver the result without making the user wait in an invisible queue.
For this interview, design a global service that produces 1024 × 1024 images, handles 100 million generations per month, and completes the normal interactive path within 25 seconds at p95. Treat the scale and benchmark numbers as explicit design assumptions, not claims about any particular commercial system.
Product invariant
Release only inspected output
Every delivered image passes prompt policy, output policy, identity checks, and provenance recording.
Critical path
Queue the expensive work
The request becomes a durable job so accelerator saturation does not become a lost or duplicated generation.
Failure mode
Degrade quality before safety
Offer a preview tier, fewer denoising steps, or a longer ETA when capacity is tight; never remove release gates.
Define the user journey
The smallest useful flow is:
- A user submits a prompt plus bounded controls such as aspect ratio, style category, and seed.
- The API authenticates the user, reserves quota, and checks the prompt against policy.
- A durable job enters a regional queue and reports an ETA.
- A scheduler assigns an approved model tier and accelerator worker.
- The system inspects the generated image, records provenance, stores the asset, and returns a signed delivery URL.
Separate functional scope from quality goals
In scope
- Generate one to four images from a prompt.
- Support 512 px previews and 1024 px standard images.
- Provide job status, cancellation, deterministic seeds, and short-lived result links.
- Enforce prompt, output, identity, tenant, quota, and provenance policy.
Out of scope for the first design
- Training a foundation model from scratch.
- User-specific fine-tuning and persistent character identities.
- Image editing, inpainting, video generation, and unrestricted custom models.
- Guaranteed pixel-level reproduction of a reference artist or copyrighted work.
State the non-functional goals
<25s
Generation p95
Queue plus inference and release checks for the standard tier.
99.9%
Job API availability
Accepted jobs remain durable across worker failures.
100M
Images per month
About 39 images/s average before the peak multiplier.
0
Unchecked releases
Safety and provenance are not degradable stages.
Ask the questions that change the architecture
- Audience and policy: Is this a family-safe consumer product, an enterprise studio, or a controlled internal tool?
- Latency and quality: Does the user need a fast preview, a high-quality final render, or both?
- Rights and identity: Are public figures, uploaded references, logos, and style imitation allowed?
- Retention: Are prompts and outputs temporary, user-owned, enterprise-isolated, or eligible for training?
- Failure behavior: Should overload return an ETA, offer a cheaper tier, reject admission, or consume prepaid quota later?
Serving strategy for the text-to-image product
Your text-to-image product serves a large free tier plus a smaller paid tier on expensive GPUs. Generation is the dominant cost, and free users vastly outnumber paid ones. How do you allocate model capacity across tiers?
Constraint: GPU cost at scale is the binding limit; free users dominate volume, and paid users are the ones who actually need top output quality.