SysPad › Lessons › diagram lessons › Users
Modelling users: where traffic enters an architecture
The entry point of the diagram - marks where traffic originates. No configuration of its own: set the target RPS and payload size in the Simulation toolbar above the canvas, not here. It also accepts an inbound Return edge, so a server push (WebSocket, SSE) can be drawn back to the client without that leg being counted as request traffic.
Every architecture diagram starts with a box that never appears in an AWS console: the people using it. In SysPad that box is Users - and dropping it onto the canvas is not decoration, it is where you declare the one number the entire simulation is built on.
What you will learn
- What does an "entry point" actually control in the simulation?
- Why does this node carry zero configuration of its own?
- What is RPS really measuring, and where do real numbers come from?
- Why does this node cost nothing and have no capacity limit?
The node that starts everything
A simulation needs a declared entry point: the node whose target RPS SysPad propagates through every downstream component, splitting at load balancers, replicating at fan-outs, until it finds your bottleneck. Users exists to BE that entry point, cleanly, instead of hijacking a real AWS node for the job.
Context is a label, not a component
An earlier version of SysPad shipped three near-identical entry nodes - Users, Web App, Mobile App - that simulated identically and differed only in icon and name. That was redundant surface area for zero simulation benefit: the same "this is mobile traffic" signal to a reader is achieved by renaming this node's label (the label field at the top of this panel), not by choosing a different component.
Where does "target RPS" come from?
RPS is not a guess, it is arithmetic: concurrent users × actions per minute ÷ 60. 10,000 concurrent users each clicking roughly once every 20 seconds is about 500 RPS. Marketing gives you concurrent users; you convert it - and a slower, more deliberate mobile flow implies a lower RPS than the same user count moving through a fast web dashboard, even though both are typed into the same Simulation-toolbar field.
⚓ Real numbers beat round numbers. "1000 RPS" as a default is a placeholder; a specific product's DAU and session shape is the input that makes the rest of the simulation worth trusting.
Peak RPS vs average RPS: which one should size my system?
Average RPS tells you the steady-state cost; PEAK RPS tells you whether the system falls over. A launch, a sale, a viral post can be 10-50x the daily average for minutes at a time. Size (and simulate) for a realistic peak, not the average, unless your product genuinely has none (an internal tool with flat usage).
No cost, no ceiling, no config: on purpose
This node has zero cost, infinite max RPS, and no tunable fields at all, because it represents DEMAND, not infrastructure. There is nothing to provision or bill for "the users wanting things," and there is nothing to configure per-node either: target RPS and payload size are set once, globally, in the Simulation toolbar above the canvas - a second copy of that control on this node would just be a confusing second place to set the same number.
Flashcards
- You import a shared diagram and the simulation button is greyed out with "no entry node selected." What is missing?
- No node is marked as the simulation entry point (usually a Users node). Without it there is no starting RPS to propagate, so nothing downstream can be computed.
- A reviewer asks "is this traffic from our iOS app or our marketing site?" while reading your diagram. What is the one-node fix?
- Rename the Users node's label to "Mobile App" (or "Web App"): same simulation math, immediately answers the reviewer's question without a caption.
- Product says "we expect 50,000 daily active users." A teammate types 50,000 into target RPS. What is wrong?
- DAU is not RPS: convert via concurrency and action rate (e.g. ~5,000 concurrent users acting once per 30s ≈ 165 RPS). Typing the raw user count in overstates load by orders of magnitude.