Decision Rules

The classic tradeoffs from across this course, distilled to one line each and the concrete condition that tips the choice.

?Decision

Choose TCP: reliability, ordering, and congestion control are built in, at the cost of handshake and head-of-line-blocking latency.

Pick this when: you need every byte delivered, in order, and can tolerate retransmission delay

?Decision

Choose UDP: no connection setup, no retransmission stalls - the application (or a protocol built on top, like QUIC) handles reliability if it needs any at all.

Pick this when: occasional loss is acceptable and latency or per-message independence matters more than delivery guarantees

?Decision

Choose L4 load balancing: it forwards connections based on the IP/port 4-tuple alone, so it is fast and protocol-agnostic, but it cannot route on URL path, headers, or cookies.

Pick this when: you need to load balance by IP/port only, at very high throughput, with no visibility into request content

?Decision

Choose L7 load balancing: it terminates and inspects the request, which costs more CPU per connection but unlocks content-based routing.

Pick this when: routing decisions depend on the HTTP request itself - path, host header, cookie-based session affinity

?Decision

Choose a forward proxy: it sits in front of clients, hiding their identity and enforcing outbound policy (content filtering, egress control).

Pick this when: you are protecting internal clients as they reach out to the internet

?Decision

Choose a reverse proxy: it sits in front of servers, hiding their identity and topology while handling TLS termination, caching, and routing.

Pick this when: you are protecting or load-balancing internal servers as clients reach in from the internet

?Decision

Choose symmetric crypto: one shared key, orders of magnitude faster than public-key crypto, which is exactly why TLS uses it for the bulk data transfer after the handshake.

Pick this when: both sides can share a secret ahead of time and you need to encrypt bulk data cheaply

?Decision

Choose asymmetric (public-key) crypto: a public/private keypair lets strangers authenticate and agree on a key without ever transmitting a secret, at a steep computational cost - which is why it is used to bootstrap the connection, not to encrypt the whole payload.

Pick this when: the two sides have no pre-shared secret and need to establish trust or exchange a key over an untrusted channel

?Decision

Choose IPv6: the address space problem that forced NAT and CGNAT workarounds onto IPv4 simply does not exist, and there is no reason to inherit IPv4's exhaustion for a design starting from zero.

Pick this when: you are standing up a brand-new deployment with no legacy constraint forcing IPv4

?Decision

Choose IPv4 (or dual-stack): a green-field preference for IPv6 does not override a hard compatibility requirement with infrastructure that only speaks IPv4.

Pick this when: you must interoperate with existing IPv4-only clients, networks, or middleboxes

?Decision

Choose polling: plain request/response on a timer, trivial to build and debug, at the cost of wasted requests and staleness up to the poll interval.

Pick this when: updates are infrequent and simplicity matters more than latency

?Decision

Choose WebSockets: one persistent full-duplex connection carries updates in both directions with no per-message handshake overhead.

Pick this when: you need low-latency, bidirectional, high-frequency updates (chat, live collaboration, gaming)

?Decision

Choose SSE (Server-Sent Events): a one-way stream over plain HTTP, simpler to operate than WebSockets (works through ordinary HTTP infrastructure, auto-reconnects) when you only need server-to-client push.

Pick this when: the server needs to push frequent updates but the client never needs to send data back over the same channel

?Decision

Choose unicast: a single, addressable destination - the normal case for most client-server traffic.

Pick this when: every request must reach one specific, identifiable server instance

?Decision

Choose anycast: the same IP address is announced from multiple locations, and routing delivers each request to the topologically closest live instance - how large-scale DNS and CDN edge nodes achieve low latency and failover without client-side logic.

Pick this when: you want each request routed to the nearest/healthiest of many identical servers, transparently, with automatic failover