Requirements for a new system list 50 internal analysts running ad hoc reports during office hours and up to 20,000 concurrent web customers placing orders through an application. What planning conclusion follows from these numbers and user types?
Select an answer to reveal the explanation.
Short Explanation
Fifty people running big reports and twenty thousand shoppers clicking buy are two very different crowds. You size the server for both, license correctly and give each group its own access path. Don't assume the people you never see aren't hitting your database.
Full Explanation
The number and type of users are core system specifications because they determine concurrency, connection management, licensing and security design. The 20,000 web customers do not connect directly, but their requests reach the database through the application, producing many short concurrent OLTP transactions that drive connection pool size, CPU, memory and locking behavior. The 50 analysts generate far fewer but much heavier queries that compete for I/O and may justify a replica or reporting store. Licensing models may be per core or per user, so counts and access paths matter commercially as well. Each group also needs a distinct role with least-privilege permissions. Ignoring the web customers is wrong because their activity is the dominant transactional load even when mediated by the application tier. Treating user counts as a licensing matter only ignores that concurrency, not just data volume, determines CPU, memory and connection sizing. Putting both groups in one role with identical permissions violates least privilege, letting the application's identity run ad hoc reports or analysts modify orders. Exam caveat: application users usually share pooled service connections, so concurrency is estimated from requests per second rather than one connection per person. Operational check: model peak requests per second and verify pool and server limits in a load test.