We Put 1,001 Members in One Workspace
"Does it scale?" is easy to claim and cheap to say, so instead of saying it we did it: we seeded a single workspace with 1,001 real members and 20 services, put the busiest pages under 30 concurrent readers, and measured. Then we fixed what the numbers exposed and measured again. This post is the before/after.
What broke first
Not the governance engine — the members page. The original implementation returned all 1,001 members in one response: a 377KB payload the browser had to parse and render on every visit, with search running client-side over the whole array. Fine at 10 members, absurd at 1,000. It's exactly the kind of thing that never shows up in a demo and always shows up in month three.
| Members page, before | After the fix |
|---|---|
| One 377KB response, all 1,001 members | Paginated: 25 per page, 9.4KB |
| Client-side search over the full array | Server-side search + role filter, indexed |
| p50 675ms under 30-way concurrent load | p50 147ms under the same load — 4.6× faster |
| Last-owner check needed the full list | Server returns the active-owner count directly |
What held up without changes
The honest part
1,001 members is pilot scale, not planet scale — we're not claiming more than we measured. But the methodology is the point: measure against a realistically large workspace before users hit the wall, fix the concrete thing the numbers point at, and publish the numbers either way. The full run details live in the repo's performance log, and How We Test OneEnv covers the unit, integration, and real-browser suites that gate every change.