Design an embedding generation platform: system design interview question

How the interviewer opens it

“Design a service that generates embeddings for large datasets and incoming updates. It must support model changes and large re-embedding jobs without disrupting consumers.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Dataset size
Models and compute
Traffic and read:write mix
Latency
Rebuild deadline
Source behavior
Consistency and durability
Retention and migration deadline
Consumer access
Scope

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Generate embeddings from a dataset export.
Apply new records, updates, and deletions.
Provide vector reads, bulk exports, and incremental changes.
Replace a model while existing consumers continue to receive current data.

Usually out of scope

Train or select the embedding model.
Extract text or divide documents into chunks.
Design vector search or ranking.
Support more than one region.

What interviewers ask about

Changes during a dataset rebuild: Live changes can overtake export records. Worker failures can leave gaps that a simple completion count does not reveal.
Model changes and consumer migration: Consumers prepare at different speeds. The previous generation must remain correct until its fixed retirement deadline.
Consumer exports and change delivery: Consumers need a precise boundary between an export and its feed. Separate writes can lose events or restore deleted records.
Capacity for live changes and bulk work: The rebuild needs sustained GPU capacity. Current consumers and migrating consumers still need fresh results during the same period.

Common mistakes

The design replaces active vectors in place during a model change.
The design lets old export results replace newer updates or restore deleted records.
The design retains the previous generation but stops its live updates after activation.
The design provides exports and feeds without a shared boundary or durable publication rule.
The design permits consumer pins beyond the promised retention window.
The capacity estimate ignores live work for the previous generation.

The bar by level

Senior (L5/E5): Defines source boundaries, revision checks, and deletion fences. Connects exports to durable feeds. Protects live capacity and enforces the migration deadline.
Staff (L6+/E6+): States correctness rules across source replay, output commits, and consumer copies. Proves completeness after partial failures. Prices dual-generation freshness and defines expiry behavior.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design an embedding generation platform
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a service that generates embeddings for large datasets and incoming updates. It must support model changes and large re-embedding jobs without disrupting consumers.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

Scope of a strong answer

Core requirements

Generate embeddings from a dataset export.
Apply new records, updates, and deletions.
Provide vector reads, bulk exports, and incremental changes.
Replace a model while existing consumers continue to receive current data.

Usually out of scope

Train or select the embedding model.
Extract text or divide documents into chunks.
Design vector search or ranking.
Support more than one region.

What interviewers ask about

Changes during a dataset rebuild

Live changes can overtake export records. Worker failures can leave gaps that a simple completion count does not reveal.

Model changes and consumer migration

Consumers prepare at different speeds. The previous generation must remain correct until its fixed retirement deadline.

Consumer exports and change delivery

Consumers need a precise boundary between an export and its feed. Separate writes can lose events or restore deleted records.

Capacity for live changes and bulk work

The rebuild needs sustained GPU capacity. Current consumers and migrating consumers still need fresh results during the same period.

Common mistakes

The design replaces active vectors in place during a model change.

The design lets old export results replace newer updates or restore deleted records.

The design retains the previous generation but stops its live updates after activation.

The design provides exports and feeds without a shared boundary or durable publication rule.

The design permits consumer pins beyond the promised retention window.

The capacity estimate ignores live work for the previous generation.

The bar by level

Senior (L5/E5)

Defines source boundaries, revision checks, and deletion fences. Connects exports to durable feeds. Protects live capacity and enforces the migration deadline.

Staff (L6+/E6+)

States correctness rules across source replay, output commits, and consumer copies. Proves completeness after partial failures. Prices dual-generation freshness and defines expiry behavior.