Do two thousand people need to work inside the same system at the same time?
Multi-user systems fail on concurrency, permissions, and performance long before they fail on features. We design for the load first and add features to something that already holds.
The problem
The request usually arrives as a feature list, and the list is fine. What is missing is the load: how many people are logged in at nine on a Monday, which of them may see which records, and what happens when two of them edit the same row within a second. Systems built feature-first tend to work perfectly in the demo and degrade in the first month of real use, and by then the schema is already the thing everyone depends on.
How we approach it
We start with the numbers — concurrent users, records per year, the slowest query anyone will accept — and with the permission model, because it shapes every table and every screen. The data model is designed to be boring: precomputed where reads dominate, transactional where writes must not be lost. Access is enforced in one place, on the server, and every screen is a view of that rule rather than a re-implementation of it. Load is tested before the first feature is polished.
Worked example
A 2,000-seat performance platform
A service organisation needed team performance figures that 2,000 people would read on the same morning, each seeing only their own scope. The naive version recomputed every metric per request and fell over at a few hundred users in testing. We moved aggregation into scheduled jobs, so a page load reads a handful of precomputed rows, and put the role scoping in a single server-side policy that every query passes through. The final load test held 2,400 concurrent sessions with page times under 300 ms; the one thing that did break was a report export that tried to stream 400,000 rows through the browser, which became a background job with an email link.
What you get
- A data model and permission model reviewed against real numbers, not a wish list
- The system itself, load-tested at the concurrency you actually expect
- Role-scoped access enforced server-side, with an audit trail of who saw what
- Runbooks and handover documentation so your own team can operate it