Client-Server Model Lab (Interactive)
Round-robin interactions across replicas and watch stateful sessions break horizontal scaling. Compare thin vs thick clients and stateful vs stateless servers by routing live requests through a replica fleet.
Client-Server Split & Stateless Scaling Lab
Route user interactions across replicas and watch stateful servers break horizontal scaling.
No interactions yet. Send a request to see how the load balancer routes it.
How It Works Under the Hood
The client-server model partitions work: clients own presentation, servers own truth — authentication, business rules, and transactions. The golden scaling rule is that app servers must hold zero per-user state; when sessions live in local memory, a load balancer round-robining across replicas randomly loses the session and returns 401, forcing sticky sessions that create hotspots and break failover. Moving state to Redis or JWTs lets any replica serve any request. Thin clients ship full HTML per interaction; thick clients ship small JSON, shifting compute to the device.
Core Architectural Principles
- Stateless servers + load balancer = any replica can serve any request; stateful pins sessions to one replica.
- Thin client costs ~48 KB server-rendered HTML per click; thick client costs ~0.9 KB JSON.
- Client-side validation is UX only — the server must re-verify every rule for security.
When proposing an app tier, say servers are stateless with sessions delegated to Redis so replicas scale without sticky sessions. Mention that thick-client SPAs reduce server CPU and bandwidth per interaction, and that the server is the only security boundary — a point interviewers listen for when probing backend-for-frontend decisions.
Centralized control and independent scaling vs a server-side single point of failure and per-interaction network latency.