Tech in Diagrams

Client-Server Architecture

Clients request, servers respond, and state lives behind the server rather than on the device.

Beginner 4 min Architecture
Clients ask · the server decides
  • Request path
  • Response path
  • Server ↔ data
SERVER — CENTRALISED PROCESSING & RULESBEHIND THE SERVER — SHARED STATECLIENT 01BrowserRenders the page, sends HTTPS requestsGET /ordersCLIENT 02Mobile appSame service, different front endPOST /ordersCLIENT 03Another applicationA machine client, no user interfaceGET /orders/42CLIENT SIDEPresentation & inputSends credentials with each requestHolds no authoritative state01 · LISTENER · :4433 REQUESTS IN FLIGHT02 · IDENTIFYWho is asking?Authenticate, then allow or refuse03 · APPLICATION LOGICThe rules run hereSame behaviour for every client04 · RESPONSEBack to the same caller200 OK · returned on the lane it arrived onDatabaseOne consistent version of the dataClients never connect to it directlyOPTIONALFile / object storageUploads, images, documentsThe server decides who may readCONCURRENCYMany at onceOverlapping, kept separateTRADE-OFFOne centreIf the server is unreachable,every client loses the serviceat the same moment.CONTRASTPeer-to-peerEveryone is bothclient and server
Several different clients send requests over the network to one server. It listens on a single address, handles the requests side by side, identifies the caller, applies the rules, reads or writes the shared data behind it, and returns each response to the client that asked.

Hover a client, a server stage or the data layer to isolate its path; click any component for a short explanation.

Next conceptMonolith vs MicroservicesA monolith deploys as one unit; microservices split the same capabilities into independently deployable services.