Bulk Import Platform

Design an asynchronous tenant data importer. Files can be huge or malformed, retries can repeat batches and users need explicit partial-versus-atomic import semantics.

Bulk work can succeed partially, so define row/batch identity and the scope of atomicity before presenting progress. Validation, committed effects and unprocessed input must remain distinguishable after errors or cancellation.

Begin with immutable input staging and deterministic bounded batches. One enormous transaction limits recovery and scalability; untracked per-row writes make retries duplicate data. Commit batch progress with its effects and report partial completion honestly.

1. Authorize and version the import source/mapping.
2. Parse and validate with bounded resource usage.
3. Make batch writes idempotent with durable progress.
4. Report rejected rows and define cancellation/partial success.

Workload: 5,000 reads/s, 10,000 writes/s, 1000 B records, 250 ms read p99 target. These are exercise assumptions; the Solution includes capacity formulas.

Validation and staging must be bounded independently from committed writes. Use deterministic row/batch identities and atomically commit each batch with its progress marker. Cancellation stops future work, while already committed batches remain visible under an explicitly partial-success contract.

A 10,000-row import commits its first three batches, then encounters invalid data. The result identifies committed, rejected and unprocessed ranges. Retrying a committed batch does not duplicate records. Cancelling the job cannot truthfully claim to undo those committed rows without a separate compensating workflow.