System designHard~20 min

Interview question

Design a backend sync that imports customer or order data from a third-party API every few minutes.

Design a reliable third-party integration sync

Designs synchronization with an external system using cursors, retries, idempotency, rate limits, and reconciliation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would store integration configuration, credentials reference, last successful cursor or timestamp, and sync status. A scheduler would enqueue sync work, and a worker would fetch pages from the third-party API, transform records, and upsert them into local tables. Each imported record would use a stable external id so repeated pages do not create duplicates. The system would track success, failure, and next retry time.

Full answer below

Practice focus

External API integration, cursoring, idempotent updates, rate limits, retries, reconciliation, and operational visibility.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
External sync is a realistic system-design prompt because the provider is slow, rate-limited, inconsistent, or temporarily unavailable. A good design does not pretend the external API is a local database.
I would store integration configuration, credentials reference, last successful cursor or timestamp, and sync status. A scheduler would enqueue sync work, and a worker would fetch pages from the third-party API, transform records, and upsert them into local tables. Each imported record would use a stable external id so repeated pages do not create duplicates. The system would track success, failure, and next retry time.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would design for partial progress. The sync can checkpoint after each page or batch, and it can retry transient provider failures with backoff. Rate limits need a per-provider and per-tenant budget. If provider data can change or be deleted, I would define reconciliation behavior: full resync windows, tombstone handling, or periodic audits. The local model may need raw payload storage for diagnosis plus normalized tables for application queries.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make the integration observable and supportable. Operators need to see lag, last success, records imported, provider errors, throttling, and stuck tenants. Credential rotation, provider schema changes, and manual replay need runbooks. The design also needs conflict rules when local edits and provider updates touch the same data. I would isolate provider instability behind a sync boundary so normal user requests do not depend directly on a slow external API.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling the third-party API directly during user requests.
No cursor, checkpoint, or idempotent upsert.
Ignoring provider rate limits.
No reconciliation when records are deleted or changed externally.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain partial progress.
Has no stable external id mapping.
No dashboard for sync lag or failures.
Treats provider data as always consistent and available.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you handle provider rate limits?
How would you recover from a bad import mapping?
What happens if local data and provider data conflict?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Abstraction vs encapsulationConcept question / Easy / ~5 minContinue Access modifiersConcept question / Easy / ~5 minContinue ActionResult vs Typed ResultsComparison question / Medium / ~7 minContinue

System designHard~20 min

Interview question

Design a backend sync that imports customer or order data from a third-party API every few minutes.

Design a reliable third-party integration sync

Designs synchronization with an external system using cursors, retries, idempotency, rate limits, and reconciliation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

External API integration, cursoring, idempotent updates, rate limits, retries, reconciliation, and operational visibility.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
External sync is a realistic system-design prompt because the provider is slow, rate-limited, inconsistent, or temporarily unavailable. A good design does not pretend the external API is a local database.
I would store integration configuration, credentials reference, last successful cursor or timestamp, and sync status. A scheduler would enqueue sync work, and a worker would fetch pages from the third-party API, transform records, and upsert them into local tables. Each imported record would use a stable external id so repeated pages do not create duplicates. The system would track success, failure, and next retry time.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would design for partial progress. The sync can checkpoint after each page or batch, and it can retry transient provider failures with backoff. Rate limits need a per-provider and per-tenant budget. If provider data can change or be deleted, I would define reconciliation behavior: full resync windows, tombstone handling, or periodic audits. The local model may need raw payload storage for diagnosis plus normalized tables for application queries.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make the integration observable and supportable. Operators need to see lag, last success, records imported, provider errors, throttling, and stuck tenants. Credential rotation, provider schema changes, and manual replay need runbooks. The design also needs conflict rules when local edits and provider updates touch the same data. I would isolate provider instability behind a sync boundary so normal user requests do not depend directly on a slow external API.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Calling the third-party API directly during user requests.
No cursor, checkpoint, or idempotent upsert.
Ignoring provider rate limits.
No reconciliation when records are deleted or changed externally.

Red flagsCandidateRed flagsSignals that an interviewer may treat as risky.Open details

Details

Cannot explain partial progress.
Has no stable external id mapping.
No dashboard for sync lag or failures.
Treats provider data as always consistent and available.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

How would you handle provider rate limits?
How would you recover from a bad import mapping?
What happens if local data and provider data conflict?

Continue practice

No explicit flow link is set yet, so these are nearby drills from the same path or taxonomy.

Design a backend sync that imports customer or order data from a third-party API every few minutes.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Design a backend sync that imports customer or order data from a third-party API every few minutes.

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice