One long-lived WireMock serves every team's pipeline. When has that shape stopped paying for itself?

## What one shared instance is actually buying A single long-lived stub server for the whole pipeline is not laziness; it is a real trade with real returns. It is always warm, so no run pays start-up. It has one address, so nothing has to be discovered or plumbed. It has one readiness contract, a `GET /__admin/health` poll, that every consumer implements once. And it has one place to look when something is wrong. For a small pipeline with a handful of suites that is a good deal, and the alternatives are more machinery than the problem deserves. The question is when the deal stops being good, and the honest answer is that it stops when the instance's **singular** surfaces become contended. ## The four things there is only one of 1. **One request journal.** Every run's traffic lands in the same sequence, and `--max-request-journal-entries` bounds that sequence for everybody at once. Sizing it is aggregate arithmetic: the cap must hold what the busiest set of concurrent runs sends together. When it is crossed, the oldest entries are evicted silently, so other teams' traffic decides when your run loses its own history. 2. **One admin API.** `--admin-api-basic-auth` decides who may reach the control surface; it does not decide who owns the mappings. Any job holding the credential can change any mapping, so the mapping set is a shared mutable object with no ownership model at all. 3. **One mapping set.** Two suites that need different answers from the same bakery pre-order endpoint cannot both be right, and the last writer wins. Teams work around this by carving out disjoint paths, and the workaround holds until somebody forgets. 4. **One health signal.** `GET /__admin/health` goes green for every consumer simultaneously and says nothing about whose mappings are loaded, so it cannot warn anyone that the instance has become unfit for their particular run. ## What it looks like when the shape has failed - Runs fail on request counts and pass on rerun with no code change, because eviction is timing-dependent and driven by unrelated traffic. - A suite's stubbed responses change mid-run and the person debugging cannot find any commit that did it. - Teams start defensively rewriting their own mappings at the top of every run, which is a shared-instance protocol nobody designed and everybody now depends on. - A restart to fix one team interrupts every pipeline, so nobody restarts it, and its uptime becomes an argument against ever changing it. - The instance grows a coordination cost: messages asking whether anybody is using it, and a rota for who may reconfigure it. That last symptom is the clearest. When keeping the shared instance usable requires humans to coordinate, it has stopped being infrastructure and become a resource to be booked. ## What to measure before deciding | measurement | what it tells you | |---|---| | unreproducible count failures per week | how much eviction or interference already costs in time | | journal turnover against the cap | whether the bound is crossed at all, and how often | | mapping changes during an active run | how much cross-run rewriting is actually happening | | pipelines interrupted by one restart | the blast radius carried on every maintenance action | | runs per hour and suites per instance | whether contention is growing or has plateaued | Numbers matter here because instinct is unreliable in both directions. Teams keep a shared instance long after it hurts because it has always been there, and teams abandon one on the strength of a single bad week that a larger journal cap would have fixed. ## What moving costs, and the position in between Giving each run its own instance removes the contention outright, because its journal, its admin surface and its mappings belong to it alone. The price is paid on every single run: start-up time, a readiness wait, and lifecycle code that has to behave when a job is cancelled. It also gives up the always-warm address that nobody had to manage. The middle position is usually the right first move. Not one instance for the estate and not one per run, but **one per team or per pipeline**. It keeps the warm address and the single readiness contract while shrinking the population that can evict your journal entries or rewrite your mappings down to people you can actually talk to. It also converts the sizing of `--max-request-journal-entries` from an estate-wide guess into a local, knowable number, and it makes the admin credential a thing one team rotates rather than a fleet-wide event. The judgment to demonstrate is that this is a contention question, not a technology question. Nothing about a stub server makes it unsuitable for sharing. What makes a particular shared instance unsuitable is the number of independent runs contending for the four things it only has one of.