Networking for Backend Engineers

Why this matters for a backend engineer. Every day you write REST controllers and call databases and neighbouring services — and all of it runs over the network: TCP, TLS, DNS, HTTP. Without understanding what happens underneath, it's easy to make the wrong call: set the wrong timeout, forget about a connection pool, or fail to see why a service "answers sometimes and not others". This section is the foundation that REST and contracts, Kubernetes, and the cloud sit on top of. Part of the study program.

The section is split into ten articles — from the overall model down to the practical things a backend engineer meets in code and in production. The knowledge is portable: it's not about a specific language or cloud, but about how the network works under any service.

Model and addressing

1. How networking works: the OSI and TCP/IP models — seven layers and four: the map that makes everything fall into place.
2. IP addresses, ports, and NAT — how a packet finds the right machine and the right service on it.
3. TCP and UDP: reliability vs speed — two ways to send data and when to use each.
4. DNS: how a domain name becomes an address — the internet's phone book and why its TTL matters for a service.

HTTP and encryption

5. HTTP: methods, statuses, headers — the language web services speak.
6. HTTPS and TLS: encryption and the handshake — how a connection becomes secure and what happens during the handshake.
7. HTTP/1.1, HTTP/2, and HTTP/3: what changed — why new versions appeared and what they give the backend.

Connections and reliability

8. Connections: keep-alive, pools, and timeouts — why opening a connection is expensive and how it affects a service's performance.
9. Load balancers and reverse proxies — how traffic reaches one of many instances of a service.
10. Networking and reliability: timeouts, retries, idempotency — the network is unreliable by nature, and code must account for it.

Related

• REST and contracts — HTTP semantics in API design.
• Kubernetes and networking in AWS — where these fundamentals show up in operations.
• Resilience style guide — timeouts and retries as rules, not improvisation.