- 1 · Physical
Transmit bits through a medium, such as cable or radio.
- 2 · Data link
Frame data on a local link. Examples include Ethernet, Wi-Fi, and switches.
- 3 · Network
Route packets between networks. Examples include IP, ICMP, and routers.
- 4 · Transport
Provide stream or datagram transport, illustrated by TCP and UDP.
- 5 · Session
Model establishment, management, and closure of sessions.
- 6 · Presentation
Model data representation, encryption, and compression. TLS, JSON, and JPEG are illustrative associations, not exact OSI implementations.
- 7 · Application
Provide application-facing network services such as HTTP, DNS, and SMTP.
The OSI model is a teaching model; real protocols do not always fit cleanly into one drawer.
How to read this model
A seven-drawer network cabinet arranged from the medium upward. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Concept redrawn from OSI 7 layer model.
The API design deep dive covers resource URLs, methods, idempotency, CRUD, and pagination. This page focuses on the protocols beneath those interface choices.
HTTP
HTTP encodes and transports data between a client and server. It is a request-response protocol. Requests and responses can cross routers, proxies, load balancers, caches, encryption terminators, and compression layers while retaining the information needed to process the request.
| Method | Typical use | Idempotent | Safe | Cacheable |
|---|---|---|---|---|
GET |
Read a resource | Yes | Yes | Yes |
POST |
Create a resource or trigger a process | No | No | When the response provides freshness information |
PUT |
Create or replace a resource | Yes | No | Rarely, when freshness information is present |
PATCH |
Partially update a resource | No | No | Rarely, when freshness information is present |
DELETE |
Delete a resource | Yes | No | No |
Idempotent means that repeating the same request has the same intended result as sending it once. It does not mean that every response body is identical. HTTP runs at the application layer over transports such as TCP and UDP.
TCP
TCP establishes and closes a connection with a handshake. Sequence numbers, checksums, acknowledgements, retransmission, flow control, and congestion control deliver a reliable ordered byte stream. Lost packets are resent. Repeated timeouts can close the connection.
Reliability costs time and memory. A server that keeps many TCP connections open needs memory for connection state. Connection pooling reduces setup work, including for connections to a cache such as Memcached. TCP fits web servers, databases, SMTP, FTP, SSH, and other workloads where complete data matters more than the latest possible packet.
Choose TCP when every byte must arrive intact or you want the transport to estimate and share network capacity.
- Handshake
Client and server exchange SYN, SYN-ACK, and ACK.
- Data
Sequence numbers identify byte positions; acknowledgements identify received progress.
- Loss
A missing segment prevents complete ordered delivery of the affected bytes.
- Retransmit
TCP retransmits under its recovery rules. The example illustrates a timeout, not every loss-recovery mechanism.
TCP transports an ordered byte stream. It does not preserve application message boundaries.
How to read this model
Two transport terminals with a replay holder and acknowledgement carriage. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Concept redrawn from How to make a multiplayer game.
UDP
UDP sends connectionless datagrams. A datagram may arrive out of order, arrive more than once, or never arrive. UDP has no built-in congestion control, so applications that use it must decide how to handle loss and rate.
UDP can broadcast to devices on a subnet. DHCP uses this property before a client has an IP address. VoIP, video chat, streaming, and real-time games often prefer a late packet to a lost moment, so they use UDP with application-specific recovery.
Choose UDP when low latency matters more than complete delivery, when late data is worse than lost data, or when the application needs its own error correction.
- Send
The client sends independent datagrams without a TCP-style handshake.
- Deliver or lose
Datagrams 1 and 3 arrive in the example; datagram 2 is lost.
- Application policy
The application decides whether and how to recover missing data and control its traffic.
UDP supplies no built-in handshake, retransmission, ordering guarantee, or congestion-control loop.
How to read this model
A datagram feeder with independent delivery and drop trays. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Concept redrawn from How to make a multiplayer game.
Real-time connections
Short polling sends repeated requests at a fixed interval. It is simple and works with ordinary HTTP, but empty responses consume connection and server resources and updates wait for the next interval.
Long polling holds one request open until data is available or a timeout occurs, then the client reconnects. It reduces empty responses but keeps server connections open.
Server-sent events (SSE) keeps one HTTP response open and streams server-to-client events with text/event-stream. It supports one-way updates and automatic reconnect patterns. The client still sends ordinary requests upstream.
WebSockets begin with an HTTP upgrade handshake and then keep a bidirectional message connection. They fit chat, presence, collaborative editing, and games. Proxies, load balancing, connection limits, and reconnect state become part of the design.
- Short polling
The client repeatedly sends requests for new information.
- Long polling
A request waits until a reply is available or its timeout is reached, then the client starts another request.
- SSE
A server-to-client event stream runs over a long-lived HTTP response.
- WebSocket
A connection permits messages in both directions.
Polling, SSE, and WebSocket differ in request lifetime and communication direction.
How to read this model
A pair of messaging terminals with selectable transfer modes. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
| Pattern | Direction | Connection | Good fit |
|---|---|---|---|
| Short polling | Client requests | Repeated short requests | Low-frequency updates and simple infrastructure |
| Long polling | Server replies when ready | Held request | Push-like updates without a protocol upgrade |
| SSE | Server pushes | Held HTTP response | One-way event streams |
| WebSocket | Both directions | Upgraded persistent connection | Interactive, low-latency sessions |
For the system-design consequences of these choices, continue with real-time backends. That explanation covers event IDs, replay, heartbeats, connection budgets, and fan-out across instances.
RPC
Remote procedure call (RPC) makes a procedure execute in another address space, usually on a server. A client stub marshals the procedure ID and arguments, the communication layer sends them, and the server stub unmarshals them before calling the implementation. The response follows the same path in reverse.
Remote calls are slower and less reliable than local calls. Keep that difference visible in the interface. Protobuf, Thrift, and Avro are common serialization or RPC technologies.
GET /someoperation?data=anId
POST /anotheroperation
{"data":"anId", "anotherdata":"another value"}
RPC exposes behavior and can fit internal traffic where a generated native client, compact encoding, or tailored error model matters. A native SDK fits when the target platform is known and the library should control how callers access logic and errors.
RPC clients can become tightly coupled to the server implementation. Every new operation may need a new procedure. Debugging and caching can require special tooling.
- Client stub
The client program calls a stub that encodes and sends a request.
- Network
The request crosses a network with latency, timeout, and failure possibilities.
- Server stub
The server decodes the request and invokes the procedure.
- Reply
Encode and return the result through the same abstraction. A timeout can leave effect status unknown.
A familiar procedure-call interface does not remove network failures.
How to read this model
A client encoding press beside a server decoding fixture. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Concept redrawn from Puncsky’s system design notes.
REST
REST is an architectural style in which clients act on resources managed by a server. A REST interface is stateless and cacheable. It identifies resources with URIs, changes representations with HTTP methods and bodies, uses HTTP status codes for errors, and can expose discoverable links through HATEOAS.
GET /people/1234
PUT /people/1234
{"display_name":"Ada"}
REST exposes data through a uniform interface and works well for public HTTP APIs. Stateless requests also simplify horizontal scaling and partitioning.
REST becomes awkward when a domain action does not map cleanly to a resource, when one screen needs deeply nested data and many round trips, or when a broad response adds fields that older clients do not need. Query parameters, a request body, a purpose-built endpoint, or RPC may express that operation more clearly.
| Operation | RPC style | REST style |
|---|---|---|
| Sign up | POST /signup |
POST /persons |
| Resign | POST /resign {"person_id":"1234"} |
DELETE /persons/1234 |
| Read a person | GET /readPerson?person_id=1234 |
GET /persons/1234 |
| Read items | GET /readUsersItemsList?person_id=1234 |
GET /persons/1234/items |
| Add an item | POST /addItemToUsersItemsList {"person_id":"1234","item_id":"456"} |
POST /persons/1234/items {"item_id":"456"} |
| Update an item | POST /modifyItem {"item_id":"456","key":"value"} |
PUT /items/456 {"key":"value"} |
| Delete an item | POST /removeItem {"item_id":"456"} |
DELETE /items/456 |
Choose the interface that keeps the caller's contract small and the server's implementation replaceable. See API design for detailed resource and method choices.