Design Bulk Operations Around Real Limits

Performance & Reliability · import/export, scale, bulk actions

Updated 2026-08-04

State the limit before the work starts. Rows, file size, and selection count all have a ceiling somewhere in the system, and discovering it after a ten minute upload is the worst way to learn it.
Process in chunks with backpressure and report progress in the same units the user chose. "1,200 of 4,000 rows" is meaningful, and a percentage of an unknown total is not.
Never load everything at once just because the interface offered Select all. A selection of forty thousand items has to become a described operation rather than a list of forty thousand identifiers.
Distinguish selecting everything on the page from selecting everything that matches. They are different operations with different costs and very different consequences when the action is destructive.
Let a long operation continue without the tab. Anything measured in minutes should survive a closed window and report its result somewhere findable.
Design the partial result honestly. A bulk action that completed 3,989 of 4,000 must say which eleven failed and offer to retry only those.
Give an expensive operation a cancel that actually stops it, and say what happens to the part already done. A cancel that leaves half the work applied without saying so is worse than no cancel.
Offer a smaller path when the limit is hit rather than only refusing. Splitting by date range, by filter, or by page turns a dead end into a workaround.

Bulk actions are where a product meets its real limits, and the interface either states them up front or discovers them in front of the user.