A job's worker processes can be few and large or many and small at one fixed total — what changes?

## One total, two shapes A job is granted a total: so much processing capacity, so much memory. Before a line of the program matters, that total is cut into **worker processes** — the processes on cluster machines that run pieces of the job and own the memory those pieces use — each running some number of **work slots**, the concurrent units of work one process may run at once. Four processes of sixteen slots and sixteen processes of four slots are the same total and a different machine. The interview answer must go in both directions. A candidate who only knows that big workers are efficient, or only that small workers are safe, has half of it. ## What few and large buys 1. **The fixed per-process cost is paid fewer times.** Every process pays for its own start-up, its own internal bookkeeping, the connections it keeps to the coordinating process and to peer workers, and one copy of any read-only data the job sent to every worker. None of that scales with the work; all of it is multiplied by the process count. With four processes instead of sixteen, the same overhead is paid four times instead of sixteen, and the difference is memory and time the job gets back. 2. **More handoffs stay inside one address space.** Two slots in the same process can pass a record as a reference; two slots in different processes must encode it into bytes and decode it again, even on one machine. Concentrating slots concentrates cheap handoffs. 3. **Fewer endpoints to connect and track.** The number of process-to-process connections and the amount of per-process bookkeeping the coordinating process carries both fall. 4. **A bigger room for an awkward unit of work.** At a fixed total, one large pool accommodates a unit with an unusually large working set that would not have fitted in any one of many small pools. The total is the same; its divisibility is not. ## What many and small buys 1. **A smaller blast radius.** Losing a process loses every slot in it. A sixteen-slot process takes sixteen units of work with it; a four-slot process takes four. 2. **Easier placement.** A large process needs one machine with that much free at once. Small processes fit into gaps a large one cannot, so the job starts sooner on a busy pool and leaves less stranded space behind. 3. **Less shared harm.** One unit of work that consumes the pool starves only its co-resident slots, and there are fewer of them. 4. **Shorter pauses in some runtimes.** Some runtimes pause to reclaim memory, and those pauses tend to grow with the size of the pool — though how strongly depends entirely on the runtime and how it is configured. | Axis | Few and large | Many and small | |---|---|---| | Fixed overhead paid | few times | many times | | Copies of data sent to all workers | few | many | | Handoffs inside one address space | more | fewer | | Largest working set a unit can hold | larger | smaller | | Work lost when one process dies | more | less | | Ease of placing on partly-full machines | worse | better | ## What does not change The concurrency does not, to a first approximation: sixty-four slots are sixty-four slots. Neither does how many pieces the input is cut into — a separate decision with its own owner — nor the total amount of data that has to move between workers, which is set by the steps in the program. Candidates often claim a reshaping reduces the movement itself; it does not. It changes how much of that movement crosses a process boundary, and what each crossing costs. ## Where designs differ - In the oldest model of this family, **each unit of work is its own operating-system process**, so the choice barely exists: slots per process is effectively one, and the fixed overhead is paid once per unit of work. - A **managed compute service** — one you hand work to and are never shown a machine by — usually exposes no shape at all. You buy capacity units; the provider decides. - On a **standing pool** — a cluster already up before your job arrives and still up after it ends — the platform may fix the shape for every tenant, in which case this becomes a platform question rather than a job question. ## How to answer it in practice Start from what one unit of work needs, not from a favourite ratio. If any unit needs a large working set, the small shape will fail on that unit while the total looks ample. If the job is long, cheap-to-restart and runs on machines that come and go, the small shape limits what each loss costs. Between those constraints, prefer fewer and larger, because the overhead you stop paying is real and immediate.