Across a Gatling suite, would you declare every steady arrival phase as constantUsersPerSec(rate).during(d) or append .randomized(), and what does Gatling actually let you control about that choice?

## What Gatling actually puts on the table This is a narrow choice with sharp edges, and it helps to state exactly what the tool gives you before arguing about which to pick. | | `constantUsersPerSec(rate).during(d)` | the same with `.randomized()` | |---|---|---| | arrival spacing | even, computed once before the run | drawn from a Poisson process | | same schedule on a rerun? | **yes**, identical offsets | **no**, never | | seed control | not applicable | **none** — taken from the clock, no DSL parameter | | head-count | rate × window in whole seconds, **rounded** | the same product **truncated**, on 3.15.1 and later — one fewer when its fraction reaches a half | | granularity between the two | none. There is no jitter percentage and no partial randomization | The head-count row is close enough to identical to plan around, but it is not literally identical: the plain step rounds `rate × seconds` while the randomized replacement truncates it. They agree on every whole product and wherever the leftover fraction is under a half; where it reaches a half they differ by one user, so `constantUsersPerSec(0.4978).during(100)` starts 50 plain and 49 randomized. Never more than one, and never at a whole rate. The last row is the important one. Gatling does not offer a middle setting. You are choosing between two fixed behaviours, not tuning one. ## The case for the plain step as the default The plain step's arrival schedule is deterministic. Run the same simulation twice against the same build and the users start at exactly the same offsets. That property is worth something concrete: when two runs disagree, you can rule the injector out without argument. Nobody gets to say *"maybe the arrivals clumped differently this time."* It also makes a profile reviewable. A reviewer reading `constantUsersPerSec(100).during(Duration.ofMinutes(10))` can compute exactly what it will do — 60,000 users, one every 10 ms — and check it against what the author claimed. There is no distribution to reason about. ## The case for `.randomized()` The honest argument for the modifier is that the even schedule is an artefact of the tool. Nothing outside a load generator starts work on a perfect 10 ms cadence. If what you are exercising is specifically how the system behaves when arrivals bunch up — a queue, a lock, a batching layer, a connection pool that is fine on average and not fine on a burst — then the even schedule can hide the very effect you came to find, and `.randomized()` is the one lever Gatling offers. What that costs you is repeatability. Because the seed comes from the clock, a run that found something interesting cannot be replayed. You cannot bisect it, you cannot hand the exact schedule to a colleague, and you cannot re-run it after a fix and know the arrivals matched. ## A policy that survives contact A workable rule, stated per phase rather than per suite: 1. **Phases whose numbers are compared across runs** use the plain step. Determinism is the point; give up realism there deliberately. 2. **Phases that exist to provoke burst behaviour** use `.randomized()`, and their findings are treated as leads to reproduce another way, never as a measurement to trend. 3. **Ramps** follow the phase they lead into, so the profile does not change character at the join. 4. **The choice is written down in the repository**, next to the profile. This matters more than which way you decide, because the two declarations differ by one appended method call and the simulation source is the only place the choice is stated. 5. **Nobody adds `.randomized()` to make a profile look more realistic** without saying which behaviour they expect it to expose. "More realistic" is not a result. ## What this choice is not Two boundaries are worth naming so the discussion stays useful. It is **not** a way to model your real traffic. Choosing an arrival pattern that reflects how work actually reaches your system is a workload-modelling question, and Gatling's contribution to it is only these two declarations. Do not let "we turned on randomized" stand in for having thought about the shape of the load. And it is **not** a tuning knob. Because there is no seed, no percentage and no partial form, there is no incremental version of this decision. You cannot dial the irregularity up for a soak and down for a regression run — you can only pick one per step. ## How to defend the decision The strongest answer in an interview is not "always use randomized" or "always use the plain form." It is: *the plain step is the default because determinism is cheap and repeatability is expensive to lose; the modifier is applied deliberately, to named phases, for a stated reason, and its findings are re-established on a deterministic profile before anyone acts on them.* That answer shows you know both what the tool guarantees and what it refuses to give you.