Bulk import is a feature customers ask for early and one that fails in more ways than almost anything else, because you are accepting a file produced by someone else's process, with someone else's idea of correctness, and attempting to turn it into valid rows in your database. Every assumption you make about that file will eventually be violated.
Process asynchronously and in a streaming fashion. Reading a whole file into memory works until someone uploads a large one and the worker is killed; streaming row by row keeps memory constant regardless of size. Combine this with the upload pattern of writing to object storage first, so the file is safely stored before processing begins and a failed import can be retried without asking the customer to upload again.
Validate in two passes rather than one. The first pass reads the whole file and validates every row without writing anything, producing a report: this many rows are valid, these twelve have problems, here is the row number and the reason for each. The customer fixes and re-uploads. The second pass, on approval, does the work. A single-pass import that stops on the first bad row after inserting four thousand good ones leaves the customer with a half-imported dataset and no clear way forward.
Decide explicitly what happens to partial failure, because the default is the worst option. All-or-nothing in a transaction is cleanest for moderate files and impractical for very large ones. Row-level tolerance with a rejects report is usually the right answer at scale - import what is valid, report what is not, and make the rejects downloadable in the same format so the customer can correct and re-submit just those.
The file format itself will surprise you, and it is worth defending specifically. Character encodings that are not UTF-8, particularly files exported from older Windows software. Byte order marks on the first header. Excel converting long numeric identifiers into scientific notation, and leading zeros disappearing from postcodes. Dates in whichever format the exporter's locale used. Embedded newlines inside quoted fields, which naive line-by-line parsing splits incorrectly. Use a real CSV parser rather than splitting on commas, and detect encoding rather than assuming it.
Finally, make the import idempotent and traceable. Give each import a record with its own identifier, tag every created row with it, and provide a way to undo it - because the customer who imports the wrong file will ask, and the alternative is a manual database intervention. Deduplicate on a business key so a re-upload updates rather than duplicates, which is what customers expect and rarely what an import does by default.
