Client-Server Architecture
See how clients and servers split responsibilities across a network boundary — and what happens when a single server can't keep up.
The core idea
A client asks for something. A server processes the request, queries a database if needed, and sends a response back. This cycle — repeated billions of times per day — is the foundation of every web application.
Client
browser / app
Network
adds latency
Server
processes logic
Database
stores data
Client never stores data
It just renders and sends requests
Server is stateless
Each request is independent by design
DB is the bottleneck
Disk I/O is 100× slower than memory
Pick a request type, then click Send Request to watch the packet travel.
🔐 Login
Check credentials against DB → verify password hash → return session token
Completed
0
requests
In flight
0
packets
Last latency
—
round trip
Last size
—
response
Request path — hover nodes for details
Mini Challenges
Apply what you've learned by solving these hands-on problems.
Trace a login request
Send a Login request and identify exactly where the database is accessed in the path.
Cache vs Database
Compare the latency of 'Load Feed' (cache) vs 'Login' (database). What's the difference?
Survive 5000 users
In the Overload tab: scale to 5,000 users without the server failing.
Fix the bottleneck
In the Overload tab: create a bottleneck (traffic > 80%), then fix it.
Why this exists
Client-server architecture separates the thing asking for work from the thing doing the work. That separation creates clean responsibility boundaries, but it also introduces latency, failure modes, and scaling questions at the network edge.
Separation of concerns
Clients handle presentation and user interaction. Servers centralize shared logic, data, and coordination.
The network is part of the design
Once the client and server are separated, latency, retries, auth, and failures become first-class design problems.
Centralization simplifies control
A server-controlled system makes updates, authorization, and data consistency easier than fully distributed peers.
Key takeaways
- Client-server is the foundation that most higher-level architectures build on.
- The client/server boundary defines latency and fault lines.
- Shared state usually lives on the server side for consistency and control.
- Scaling starts by understanding which server responsibilities are becoming hot.