Networking

Overview Push and pull describe which side initiates a data transfer between two systems: in a push model the source sends data as soon as it’s ready, while in a pull model the consumer requests data on its own schedule. The choice shapes latency, backpressure handling, and how tightly the two sides are coupled in time. Comparison Diagram PushPullSourceConsumersends datawhen readySourceConsumerrequests dataon its scheduleSource controls timingConsumer controls timing Comparison Table Aspect Push Pull Initiator Source system triggers the transfer Consumer system triggers the transfer Timing control Source decides when data is sent Consumer decides when to fetch Latency to consumer Near-immediate once source has data Bounded by polling interval, not source readiness Backpressure handling Source must slow down or buffer if consumer is overwhelmed Consumer naturally paces itself by requesting only when ready Coupling Source needs to know consumer’s address/endpoint Consumer needs to know source’s address/endpoint Resource cost when idle No wasted work; nothing sent if no updates Repeated requests even when nothing changed Failure handling Source retries or queues if delivery fails Consumer retries the pull on its own next cycle Typical mechanisms Webhooks, pub/sub, server-sent events Polling, cron jobs, request/response APIs Key Differences Push minimizes latency by sending data the instant it’s available, while pull bounds latency to the polling interval. Pull gives the consumer natural backpressure control since it only asks for data when ready to process it. Push requires the source to hold a reference to every consumer’s endpoint, increasing fan-out coupling. Pull wastes resources on empty polls when there’s nothing new to fetch. Push systems need retry or queueing logic on the sender side; pull systems just retry the request on the next cycle. When to Use Each Push ...

Overview This comparison covers whether a server or protocol retains session state between requests, or treats every request as a fully self-contained unit with no memory of prior ones. The choice determines how you scale, fail over, and route traffic across instances. Comparison Diagram StatefulStatelessClientServer Asession: id=42must returnto same serverServer Bno session dataClientcarries tokenServerServerany server canhandle the requestStateful: server pins session context and routing depends on itStateless: request carries all context, any node can serve it Comparison Table Aspect Stateful Stateless Request context Server retains prior interaction data across requests Each request carries all context needed to process it Session storage Held in server memory or local session store None on server; state lives in client token or database Routing requirement Requests must reach the same server (sticky sessions) Any server instance can handle any request Scaling model Vertical or sticky-session horizontal scaling only Trivial horizontal scaling, load balance freely Failure recovery Server crash loses in-memory session unless replicated Server crash has no session impact, retry hits any node Client design Client can be thin, server tracks progress Client or token must resend full context each call Typical examples Database connections, WebSocket sessions, FTP REST APIs, HTTP with JWT, DNS lookups Key Differences Stateful servers keep session memory; stateless servers keep none between calls Stateless systems need no sticky routing, simplifying load balancers Stateful failover requires session replication to avoid data loss Stateless designs push state into the client or token instead of the server Horizontal scaling is near-free for stateless architectures When to Use Each Stateful ...

Overview Latency and throughput are two orthogonal measures of system performance: latency is the time a single request takes to complete, while throughput is the volume of work a system finishes per unit of time. The distinction matters because architectures optimized for one can quietly degrade the other. Comparison Diagram Latency Client Server Time for ONE request to complete Throughput Client Server Total requests completed per second Comparison Table Aspect Latency Throughput Definition Time elapsed for one request to travel and complete Amount of work completed across all requests per unit time What is measured A single request’s round trip or processing delay Aggregate output of the system over an observation window Unit of measurement Milliseconds, microseconds, or seconds Requests/sec, transactions/sec, or Mbps Primary driver Network round-trip time, serialization, and processing delay Available bandwidth, parallel capacity, and resource pool size Effect of concurrency Individual request latency can rise as queueing builds up Throughput rises with more parallel workers, up to a capacity limit Behavior under overload Tail latency spikes as queues grow (p95/p99 degrade) Throughput plateaus or drops once the system saturates Typical optimization Reduce round trips, cache results, shorten the critical path Batch requests, add parallel workers, scale out capacity Measurement method Ping, request timers, percentile latency (p50/p95/p99) Requests-per-second counters, load testing, capacity benchmarks Key Differences Latency measures the time for one request; throughput measures the volume processed per unit time. Batching to raise throughput can increase tail latency for individual requests. Latency is bounded by physical round-trip time; throughput is bounded by system capacity. Under heavy load, latency spikes from queueing while throughput plateaus at a ceiling. Little’s Law links the two: average latency times concurrency roughly equals throughput. When to Use Each Latency ...

Overview Client-Server and peer-to-peer describe who talks to whom on a network: one funnels every request through a central server, the other lets nodes exchange data directly as equal peers. The choice shapes scalability, fault tolerance, and who ultimately controls the data. Comparison Diagram Client-ServerPeer-to-PeerServerCCCAll requests routed through serverPPPPPPeers connect directly to each other Comparison Table Aspect Client-Server Peer-to-Peer Node roles Clients and servers have fixed, asymmetric roles Every node acts as both client and server (servent) Connection establishment Clients connect to a known server address (DNS/IP) Nodes discover peers via bootstrap lists, DHTs, or trackers Request handling Server processes and responds to each client request Any peer can serve or request data from any other peer Resource provisioning Server owns the compute, storage, and bandwidth Resources are contributed and shared across participating peers Scalability pattern Scaling requires adding server capacity or replicas Scaling often improves as more peers join and share load Fault tolerance Server outage disrupts all clients (single point of failure) Network tolerates individual peer failures; no single point of failure Security & trust Trust is centralized; server enforces auth and access control Trust is distributed; peers must verify each other independently Typical examples Web apps, REST APIs, email, banking systems BitTorrent, blockchain networks, LAN gaming Key Differences Client-Server relies on a central server as the single source of truth; peer-to-peer distributes data with no authoritative hub. Adding capacity in client-server means scaling the server tier; in peer-to-peer, each new node can add capacity to the network. A server outage is a single point of failure for client-server, while peer-to-peer degrades gracefully as peers leave. Client-server centralizes access control, while peer-to-peer pushes trust and verification onto each peer. When to Use Each Client-Server ...

Overview A load balancer spreads incoming traffic across many identical backend servers so no single machine gets overwhelmed, while a reverse proxy sits in front of one or more servers to mediate, secure, and transform requests on their behalf. The two overlap heavily in practice — most modern reverse proxies (NGINX, Envoy, HAProxy) can also load balance — but the distinction matters when you’re deciding which capability you actually need to configure or scale for. ...

Overview Both connect a VPC to the internet, but they serve opposite purposes: an Internet Gateway lets public-facing resources send and receive traffic directly, while a NAT Gateway lets private resources reach out without ever being reachable from outside. Picking the wrong one either exposes resources you meant to keep private or silently blocks the outbound access your servers need. Comparison Diagram Internet GatewayNAT GatewayInternetInternetno inboundIGWNAT GatewayPublic SubnetInstancehas public IPPrivate SubnetInstanceprivate IP onlybidirectional trafficoutbound only Comparison Table Aspect Internet Gateway NAT Gateway Primary purpose Enables communication between a VPC and the internet in both directions Enables outbound-only internet access for resources without public IPs Traffic direction Bidirectional — accepts inbound connections and sends outbound Outbound only — inbound traffic allowed only as replies to established connections Placement Attaches directly to the VPC as a whole Deployed inside a specific public subnet IP address handling 1:1 NAT between a private IP and an Elastic/public IP Many-to-one PAT — many private IPs share the gateway’s public IP Which resources use it Instances with a public/Elastic IP routed via a public subnet route table Instances with only private IPs routed via a private subnet route table Scaling and availability Managed, horizontally scaled, highly available with no bandwidth cap Bandwidth-bounded per gateway; needs one per AZ for high availability Cost model No hourly charge and no data processing fee Hourly charge plus per-GB data processing fee Failure impact Loss cuts off all direct internet reachability for the public subnet Loss cuts off outbound internet access for the private subnet only Key Differences Internet Gateway provides bidirectional access; NAT Gateway only permits outbound connections. Internet Gateway attaches to the whole VPC; NAT Gateway lives inside a specific subnet. Internet Gateway does 1:1 Elastic IP mapping; NAT Gateway does many-to-one PAT. NAT Gateway bills per GB processed; Internet Gateway is free. When to Use Each Internet Gateway ...

Overview An Availability Zone is one or more physically isolated data centers with independent power, cooling, and networking, while a Region is a broader geographic area made up of multiple such zones connected by low-latency links. The distinction matters because it determines what kind of failure your architecture survives — a single data-center outage versus a region-wide disaster — and what compliance jurisdiction your data falls under. Comparison Diagram Availability ZoneDCDC1+ data centers,independent power & networkRegionAZAZAZMultiple AZs,low-latency links Comparison Table Aspect Availability Zone Region Definition One or more discrete data centers with independent power, cooling, and networking A geographic area containing multiple availability zones Physical composition Typically 1+ physical data center buildings Multiple AZs (often 3 or more) plus regional network backbone Inter-node latency Sub-millisecond to a few milliseconds over private links between AZs Tens to hundreds of milliseconds over public/backbone links between regions Failure isolation Isolates against power, cooling, or single data-center failures Isolates against natural disasters or systemic events affecting an entire geography Redundancy pattern used for High availability within one geographic area Disaster recovery and global latency reduction across geographies Data residency & compliance No effect — all AZs in a region share the same jurisdiction Determines the legal jurisdiction and data residency boundary Data transfer cost Low intra-region rate for traffic between AZs Higher inter-region or egress rate for traffic between regions Key Differences An Availability Zone is one or more data centers, while a Region is the geographic area that groups several AZs together Inter-AZ traffic uses low-latency private links; inter-region traffic crosses public backbone networks with far higher latency Multi-AZ deployments protect against data-center outages; multi-region deployments protect against regional disasters Region choice fixes your data residency and compliance jurisdiction — AZ choice does not Cross-AZ transfer is cheap; cross-region transfer incurs higher egress costs When to Use Each Availability Zone ...

Overview A CDN is a distributed network of edge servers that caches and delivers content close to users, while the origin server is the single authoritative source where that content is created or stored. The distinction matters for latency, scalability, and resilience, since most requests should never need to reach the origin at all. Comparison Diagram ClientCDNDistributed edge locationsCache: static & edge-computed contentOrigin ServerSingle sourceof truthrequestcached responseon cache missorigin pull & cacheMost requests resolve at the edge; only misses/dynamic content reach the origin Comparison Table Aspect CDN Origin Server Role in request path Intercepts requests at the edge and serves cached content directly Authoritative backend that generates or stores the original content Geographic distribution Many points of presence worldwide, close to end users Typically one or a few fixed data center locations Content served Cached copies of static assets or cacheable API responses Dynamically generated pages or master copies of files Cache miss handling Forwards uncached requests to the origin and stores the response per TTL Processes every request that reaches it; has no caching layer of its own Latency Low, since content is served from the nearest edge node Higher, since every request travels to one fixed location Load on backend Absorbs most traffic, shielding the origin from direct load Only handles cache misses and non-cacheable requests Resilience to outages Can keep serving stale cached content if the origin goes down Site is effectively unavailable for anything not already cached elsewhere Scaling and cost Scales via the CDN provider’s global network, billed per bandwidth/requests Must be scaled and provisioned directly, billed for compute and hosting Key Differences CDN content lives on distributed edge nodes; the origin server is the single source of truth. CDN caching cuts latency for users, but every cache miss still lands on the origin. CDN edge caching gives resilience against origin outages by serving stale content. Origin servers own dynamic content generation; CDNs only store what’s actually cacheable. When to Use Each CDN ...

Overview An API gateway sits at the edge of your system, managing traffic between external clients and your services. A service mesh operates inside the cluster, managing traffic between services themselves. Confusing the two leads teams to either duplicate cross-cutting concerns or push edge-only features into infrastructure that was never designed for public-facing traffic. Comparison Diagram API GatewayService MeshClientAPI GatewayauthN · rate limitrouting · transformclusterService AService BService Csidecar proxymTLS · retriesnorth–south: client-to-serviceeast–west: service-to-service Comparison Table Aspect API Gateway Service Mesh Traffic direction North-south: external clients entering the system East-west: internal service-to-service calls Deployment topology Centralized cluster of edge instances fronting all traffic Sidecar proxy injected alongside every service instance Primary concerns AuthN/authZ, rate limiting, request/response transformation, API versioning mTLS, load balancing, retries, circuit breaking between services Routing basis Public API path, host, or version mapped to a backend service Service identity and destination within the internal network Observability scope Per-endpoint metrics: request volume, latency, errors by client Full service dependency graph: per-hop latency and error rates Failure containment Blocks or throttles bad traffic before it reaches any backend Isolates failures at individual hops so one bad service doesn’t cascade Operational overhead Few instances to scale and configure centrally One proxy per workload, plus a control plane to manage them all Key Differences An API gateway is the single entry point clients hit; a service mesh has no single entry point, it’s woven through every service. Gateways enforce policy once at the edge; meshes enforce policy per sidecar on every call. Gateways typically run as a small number of centralized instances; meshes scale linearly with your service count. Meshes give you mTLS and retries between internal services, something a gateway never sees because that traffic never reaches it. Many production systems run both together, not as alternatives, since they solve problems at different layers. When to Use Each API Gateway ...

Overview A VPN creates an encrypted tunnel for all of a device’s network traffic through a remote server, while a proxy forwards traffic from a single app or protocol through an intermediary server, typically without encryption. The distinction matters because it determines what’s protected, how much overhead is added, and what happens when the connection fails. Comparison Diagram VPNProxyDevice (OS)all apps & trafficencrypted tunnelVPN ServerInternetEncrypts & routes ALL device trafficBrowserapp trafficProxy ServerOther Appsbypasses proxy (direct, unencrypted)InternetRoutes only configured app/protocol traffic Comparison Table Aspect VPN Proxy Scope of traffic routed All network traffic from the device (OS-level) Traffic from a specific app or protocol the client is configured to use Where it’s configured System network settings / dedicated client that creates a virtual interface Individual app settings (browser, OS network stack per-app, or system-wide proxy field) Encryption Encrypts traffic between device and VPN server by default No encryption by default; only as strong as the underlying protocol (e.g. HTTPS) Authentication to server Client authenticates with certificates/credentials to establish the tunnel Often none, or simple username/password at the app layer Visibility to local network/ISP ISP and local network see only encrypted tunnel traffic to one endpoint ISP sees the proxy connection plus any traffic from unproxied apps Performance overhead Higher — encryption and full traffic redirection add latency Lower — only proxied traffic is redirected, often with caching Typical use case Secure remote access to a private network, or system-wide privacy on untrusted Wi-Fi Per-app geo-bypass, content filtering, or caching for a single protocol Behavior on failure Well-configured clients include a kill switch that blocks all traffic if the tunnel drops Only the proxied app’s connection fails; other traffic is unaffected Key Differences A VPN operates at the OS network layer, capturing all traffic, while a proxy operates at the application layer for one app or protocol VPN traffic is encrypted by default; proxy traffic is unencrypted unless the underlying protocol adds it VPNs require dedicated client software creating a virtual interface; proxies need only an IP:port entry in an app’s settings A VPN’s kill switch can block all traffic on disconnect; a proxy failure only drops that single app’s connection When to Use Each VPN ...