How do you run a Testcontainers-backed suite in parallel without containers fighting each other?

## Two parallelisms, two failure modes "Run the tests in parallel" hides two very different mechanisms, and the right container strategy depends on which one you mean. **Forked JVMs.** The build tool starts several test JVMs and distributes classes among them — `maxParallelForks` in Gradle, `forkCount` in Maven Surefire. Each fork is a separate process with its own static state, so a singleton container is initialised once per fork. Isolation is excellent and requires no test changes; the cost is multiplication of everything the container consumes. **Threads inside one JVM.** JUnit 5 can run test classes and methods concurrently in one process when parallel execution is enabled in its configuration. Nothing is duplicated — the same static container serves every thread — so this is far cheaper, and far more demanding of your tests. ## Ports are not the problem Candidates often expect port conflicts. There are none: Testcontainers publishes each exposed container port on a random free host port chosen by the daemon at start time, and you read it back rather than assuming it. Ten Postgres containers can run simultaneously with no coordination. Conflicts only appear if someone forces a fixed host port, which is why the mapped-port API exists. ## What forked JVMs really cost The number to compute is: forks × containers-per-fork × memory-per-container, plus the JVMs themselves. A suite that starts Postgres, Kafka and a mock service per fork can consume several gigabytes at four forks, and the machine — especially a shared CI runner also serving other jobs — starts swapping or killing processes. The symptom is unhelpfully indirect: connection timeouts and startup failures in *random* test classes, which look like flaky tests but are host contention. Each fork also pays its own container startup, so speed-up is sublinear. Beyond a modest number of forks you can spend more on starting containers than you save on parallelism. ## What in-JVM parallelism really costs Sharing one container between concurrent threads means every test sees every other test's writes *while they are happening*. Cleanup strategies that reset global state — truncating tables before each test — become destructive: one test wipes another's data mid-flight. The only strategies that survive are those that partition the namespace: a schema per test class, unique generated identifiers, unique topic or key prefixes. If the suite cannot be made to work that way, forked JVMs are the honest choice. ## Practical sizing Start from the machine, not from the core count. Measure the resident memory of one fork with its containers, divide the memory you are willing to spend, and cap forks there — then check that the wall-clock time actually improved. Keep containers shared within a fork (the singleton pattern) so the per-fork cost stays at one container set. On a machine that also runs other work, leave headroom rather than saturating it; a suite that is fast only on an idle machine is not fast. ## Cleanup under parallelism Each test JVM has its own Testcontainers session, so the reaper cleans up that fork's containers when the fork exits. Forks that die abruptly still get cleaned up, which is one reason not to hand-roll container lifecycle around a parallel build. ## Interview framing The distinguishing answer states the two models, notes that ports are a non-issue, and picks a strategy from a resource budget rather than a core count — then names the tell that you overshot: random connection timeouts across unrelated classes.