Client–server & request/response
Client–server & request/response
Stub
A client sends a request over the network; a server does work and sends a response. Every hop adds latency and one more way to fail.
- Use when
- Web and API systems — it is the default shape
- Avoid when
- Peer-to-peer or offline-first apps with no single authority
- Trade-offs
- A central server keeps data consistent but becomes a bottleneck and a single point of failure
2 objectives · 2 misconceptions
- explain Trace a request from client to server and back, naming where time goes: network, waiting, processing.
- explain Explain why each request should carry everything the server needs to handle it.
- Not true: The network is instant and always delivers.
- Not true: One user action touches exactly one server.
Learn
No lesson yet — this station is a stub. The codex card above is the short version.
Practice
No katas practice this yet.
Check
No test-out yet — it needs live questions.
Neighborhood
builds onnothing — a starting point
→Client–server & request/response→