Design a reverse ETL platform: system design interview question

How the interviewer opens it

“Design a platform that copies customer data from a data warehouse into tools such as a CRM. Keep destination data current as warehouse results change.”

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

Scale
Traffic and data size
Schedule and latency
Admission and freshness
Warehouse query
Destination contract
Destination failures
Consistency and durability
Fields and scope
Tenant boundaries

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

Configure a warehouse query, a customer key, and a field map for each job.
Copy the initial result and send later changes to the destination.
Respect destination limits across jobs that share credentials.
Recover failed writes and report progress for each row.

Usually out of scope

Load source data into the warehouse.
Build a visual tool for data transformation.
Copy destination changes into the warehouse.
Delete customers when they leave a query result.
Survive a regional failure.

What interviewers ask about

Changes in warehouse results: A join can change a customer result without changing that customer's source timestamp. Repeated full queries can also dominate cost.
Incomplete destination writes: An old request can overwrite a newer success. A paused worker can also send after recovery assumes its request lifetime has ended.
Destination capacity: Jobs share a fixed external quota. Freshness depends on destination completion as well as source work and dispatch capacity.

Common mistakes

The design assumes a customer timestamp captures changes from every join and computed field.
The design treats a completed warehouse read as proof of successful destination delivery.
The design retries batches without tracking results for each row.
The design promises freshness without admission limits or a budget for destination completion.
The design starts the remote lifetime at attempt creation and ignores a paused sender.
The design forgets uncertain writes after a newer success and waits for warehouse hashes to change.

The bar by level

Senior (L5/E5): Separates source progress from delivery progress. Calculates admission and freshness through destination commit. Handles partial batches, worker failures, and fairness. Preserves uncertain attempts and independent repair work.
Staff (L6+/E6+): Derives source and destination admission bounds. Proves repair safety for paused senders and late commits. States weaker connector guarantees. Defines regional ownership transfer only if the interviewer asks the regional failure follow-up.

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 a reverse ETL platform
Reported date not specified
Source snapshot: Nov 12, 2026
View source

Scope of a strong answer

Core requirements

Configure a warehouse query, a customer key, and a field map for each job.
Copy the initial result and send later changes to the destination.
Respect destination limits across jobs that share credentials.
Recover failed writes and report progress for each row.

Usually out of scope

Load source data into the warehouse.
Build a visual tool for data transformation.
Copy destination changes into the warehouse.
Delete customers when they leave a query result.
Survive a regional failure.

What interviewers ask about

Changes in warehouse results

A join can change a customer result without changing that customer's source timestamp. Repeated full queries can also dominate cost.

Incomplete destination writes

An old request can overwrite a newer success. A paused worker can also send after recovery assumes its request lifetime has ended.

Destination capacity

Jobs share a fixed external quota. Freshness depends on destination completion as well as source work and dispatch capacity.

Common mistakes

The design assumes a customer timestamp captures changes from every join and computed field.

The design treats a completed warehouse read as proof of successful destination delivery.

The design retries batches without tracking results for each row.

The design promises freshness without admission limits or a budget for destination completion.

The design starts the remote lifetime at attempt creation and ignores a paused sender.

The design forgets uncertain writes after a newer success and waits for warehouse hashes to change.

The bar by level

Senior (L5/E5)

Separates source progress from delivery progress. Calculates admission and freshness through destination commit. Handles partial batches, worker failures, and fairness. Preserves uncertain attempts and independent repair work.

Staff (L6+/E6+)

Derives source and destination admission bounds. Proves repair safety for paused senders and late commits. States weaker connector guarantees. Defines regional ownership transfer only if the interviewer asks the regional failure follow-up.