After this lesson, you will be able to: Know the networking a developer needs day to day: DNS records and how to configure a custom domain, CDNs and caching, HTTP/2 and HTTP/3, WebSockets vs polling vs SSE, and load balancing concepts.
This is networking from the developer's seat, not the attacker's: the knowledge you need to deploy to a custom domain, make a site fast, and choose the right real-time approach. It covers DNS records, CDNs and cache control, HTTP/2 and HTTP/3, WebSockets, and load balancing. The Cybersecurity track covers the attack perspective separately.
Deploying to a custom domain means editing DNS records. An A record points a name to an IPv4 address; AAAA to IPv6; a CNAME aliases one name to another (common for pointing www or a subdomain at a platform like Vercel); MX routes email; TXT holds verification and policy data (domain verification, SPF/DKIM for email); and NS delegates the domain to its nameservers. When Vercel or Netlify tells you to 'add a CNAME,' this is what they mean. Changes propagate over the record's TTL.
A CDN (content delivery network) caches your static assets on edge servers around the world so users download from a nearby node instead of your origin, cutting latency. A cache hit serves from the edge; a miss fetches from the origin and caches it. You control caching with Cache-Control headers (max-age, immutable for content-hashed files, no-store for dynamic responses) and purge the cache when content changes. Content-hashed filenames (app.3f9a.js) let you cache forever and bust the cache by changing the name.
HTTP/1.1 sends one request at a time per connection, causing head-of-line blocking. HTTP/2 multiplexes many requests over one connection and compresses headers, so many small assets load far faster. HTTP/3 runs over QUIC (built on UDP) instead of TCP, which removes TCP's head-of-line blocking and speeds up connection setup, especially on flaky mobile networks. You usually get these automatically from your CDN or host; knowing what changed explains why bundling many tiny files matters less than it used to.
For real-time features, pick the right transport. Polling repeatedly asks the server for updates (simple, wasteful, laggy). Server-Sent Events (SSE) give a one-way server-to-client stream over HTTP (great for notifications and feeds, auto-reconnects). WebSockets give a persistent two-way connection (needed for chat, multiplayer, collaborative editing). Use SSE when only the server pushes; use WebSockets when both sides send; avoid polling unless updates are rare and infrequent.
When one server is not enough, a load balancer spreads requests across several. Round robin rotates evenly; least connections sends to the least-busy server; sticky sessions pin a user to one server (needed if session state lives in memory, though externalizing state is better). Health checks let the balancer stop sending traffic to a server that is failing. As a developer you rarely configure these by hand, but understanding them explains why stateless services scale more easily.
Pick one.
Using an A record where the platform needs a CNAME (or vice versa). Forgetting TTL means DNS changes are not instant. Caching dynamic, user-specific responses (leaking one user's data to another). Reaching for WebSockets when SSE would do. Keeping session state in server memory and then needing sticky sessions to scale. Not setting long cache lifetimes on content-hashed assets, leaving performance on the table.
Sign in and purchase access to unlock this lesson.