feat: add IP Addresses, Client-Server Model, and API Gateway content sections

Added comprehensive course content sections (not just Q&A) to pages that
previously only had interview questions for these topics:

- 01-fundamentals.html: IP Addresses (IPv4/IPv6, public/private IPs, NAT,
  CIDR/subnets, static vs dynamic IPs, loopback) and Client-Server Model
  (request-response cycle, server types, P2P comparison, horizontal scaling,
  2-tier vs 3-tier, real-world example)

- 09-communication.html: API Gateway (routing, auth, rate limiting, SSL
  termination, request transformation, caching, observability; comparison
  with load balancers and service meshes; rate limiting internals;
  failure modes; real-world products)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: sridhar-3009

topics/01-fundamentals.html

@@ -479,6 +479,44 @@ <h4>Confusing performance and scalability fixes</h4>
  </div>
  </section>
 
+ <!-- ============ IP ADDRESSES CONTENT ============ -->
+ <section class="section-block reveal">
+  <h2>IP Addresses</h2>
+  <p>An IP (Internet Protocol) address is a unique numerical label assigned to every device on a network. It serves two purposes: identifying the host or network interface, and providing the location of the device in the network so data can be routed to it correctly.</p>
+
+  <p><strong>IPv4</strong> uses 32-bit addresses written as four decimal octets separated by dots (e.g., <code>192.168.1.1</code>). This gives roughly 4.3 billion possible addresses — a number that ran out as the internet grew. <strong>IPv6</strong> uses 128-bit addresses written in hexadecimal groups separated by colons (e.g., <code>2001:0db8:85a3::8a2e:0370:7334</code>), providing 340 undecillion addresses — effectively limitless for the foreseeable future. IPv6 also adds built-in security (IPSec), better routing efficiency, and no need for NAT.</p>
+
+  <p><strong>Public vs. Private IP Addresses:</strong> Public IPs are globally routable on the internet and assigned by ISPs — every web server you access has one. Private IPs are used inside local networks (home, office, data centre) and are not routable on the public internet. The reserved private ranges are <code>10.0.0.0/8</code>, <code>172.16.0.0/12</code>, and <code>192.168.0.0/16</code>. Your laptop at home has a private IP; your router has the public IP.</p>
+
+  <p><strong>NAT — Network Address Translation:</strong> Because private IPs cannot communicate directly on the internet, NAT lets an entire network share a single public IP. The router rewrites the source IP of outgoing packets to the public IP, tracks active connections in a translation table, and rewrites incoming responses back to the originating private IP. This is how millions of home devices share one public address from an ISP.</p>
+
+  <p><strong>CIDR and Subnets:</strong> CIDR (Classless Inter-Domain Routing) notation expresses an IP address range compactly: <code>10.0.0.0/24</code> means the first 24 bits are the network prefix and the remaining 8 bits are host addresses (256 addresses, 254 usable). Subnetting divides a large network into smaller segments to improve security, reduce broadcast traffic, and allow fine-grained routing. Cloud VPCs (Virtual Private Clouds) always use CIDR to define address spaces.</p>
+
+  <p><strong>Static vs. Dynamic IPs:</strong> A static IP is fixed and never changes — used for servers, printers, and devices that must always be reachable at the same address. A dynamic IP is assigned temporarily by DHCP (Dynamic Host Configuration Protocol) and may change when a device reconnects. Home users typically get dynamic IPs from their ISP; production servers require static IPs (or elastic IPs in cloud environments).</p>
+
+  <p><strong>Loopback and Special Addresses:</strong> <code>127.0.0.1</code> (or <code>localhost</code>) is the loopback address — traffic sent here never leaves the machine and is used for testing local services. <code>0.0.0.0</code> means "all interfaces" when binding a server socket. <code>255.255.255.255</code> is the broadcast address (send to all devices on the subnet).</p>
+ </section>
+
+ <!-- ============ CLIENT-SERVER MODEL CONTENT ============ -->
+ <section class="section-block reveal">
+  <h2>The Client-Server Model</h2>
+  <p>The client-server model is the foundational architecture of the modern web. A <strong>client</strong> is any process that initiates a request for a service or resource. A <strong>server</strong> is a process that listens for and responds to those requests. The two communicate over a network using a well-defined protocol (HTTP, TCP, WebSockets, etc.).</p>
+
+  <p><strong>How it works:</strong> The client sends a request (e.g., <code>GET /api/products</code>) including headers, authentication tokens, and optionally a body. The server receives the request, validates it, executes the business logic (queries a database, calls other services), and returns a response with a status code, headers, and a body (HTML, JSON, binary data). The client then renders or processes that response. This request-response cycle repeats for every interaction.</p>
+
+  <p><strong>Types of clients:</strong> Web browsers (Chrome, Safari), mobile applications (iOS, Android), command-line tools (curl, wget), API clients (Postman, other backend services), and IoT devices all act as clients. The defining characteristic is that the client initiates the communication.</p>
+
+  <p><strong>Types of servers:</strong> Web servers (NGINX, Apache) serve HTTP responses. Application servers (Node.js, Tomcat, Gunicorn) run business logic. Database servers (PostgreSQL, MySQL, MongoDB) store and query data. File servers store and serve files. Cache servers (Redis, Memcached) serve fast in-memory data. A real production system chains several of these together — the client talks to a web server, which delegates to an application server, which reads from a database server.</p>
+
+  <p><strong>Client-Server vs. Peer-to-Peer (P2P):</strong> In client-server, the server is a dedicated, always-on machine and the clients are transient. In P2P (BitTorrent, blockchain nodes), every participant can be both client and server simultaneously. P2P is more resilient (no single point of failure) but harder to secure and control. Most production systems use client-server because it is easier to reason about, scale, monitor, and secure.</p>
+
+  <p><strong>Scaling the server side:</strong> A single server eventually becomes the bottleneck. Vertical scaling (bigger machine) has limits. Horizontal scaling (multiple server instances behind a load balancer) is the standard approach for production. Stateless servers — where the server holds no session data between requests — are easy to scale horizontally because any server can handle any request. Stateful servers (holding session data in memory) require sticky sessions or external session stores (Redis) to scale.</p>
+
+  <p><strong>The two-tier and three-tier models:</strong> A two-tier model has the client talk directly to the database — simple but insecure and hard to scale. The three-tier model (client → application server → database) is the industry standard: the application server enforces business logic and access control, and the database is never exposed directly. Additional tiers (cache, API gateway, CDN) are added as traffic grows.</p>
+
+  <p><strong>Real-world example — how a tweet loads:</strong> Your browser (client) sends an HTTPS GET request to Twitter's CDN edge. The CDN serves cached assets; the dynamic feed request goes to Twitter's load balancer, which routes to an application server. The application server queries a distributed database cluster and a Redis cache for your timeline. The response travels back through the chain in milliseconds — each layer adding capability while hiding complexity from the client.</p>
+ </section>
+
  <!-- ============ INTERVIEW QUESTIONS ============ -->
  <section class="section-block reveal">
  <div class="section-badge">Interview Prep</div>

topics/09-communication.html

@@ -373,6 +373,33 @@ <h2>GraphQL — Query What You Need</h2>
  <p><strong>When GraphQL:</strong> complex APIs with many entity types, mobile clients needing custom response shapes, and rapid frontend iteration without backend changes. <strong>When REST:</strong> simple CRUD, public APIs, and anywhere HTTP caching matters — GraphQL's everything-is-a-POST makes caching much harder.</p>
  </section>
 
+ <!-- ============ API GATEWAY CONTENT ============ -->
+ <section class="section-block reveal">
+  <h2>API Gateway</h2>
+  <p>An API Gateway is a managed reverse proxy that sits between clients and your backend services, acting as the single entry point for all external requests. Instead of clients knowing the address of every microservice, they call the gateway — which handles routing, authentication, rate limiting, caching, and protocol translation on their behalf.</p>
+
+  <p><strong>Core responsibilities:</strong></p>
+  <ul class="feature-list">
+   <li><strong>Request routing</strong> — maps incoming paths to the correct backend service (e.g., <code>/api/orders</code> → Order Service, <code>/api/users</code> → User Service)</li>
+   <li><strong>Authentication &amp; authorization</strong> — validates JWT tokens, API keys, or OAuth credentials before the request reaches any backend; backends never deal with raw auth</li>
+   <li><strong>Rate limiting &amp; throttling</strong> — enforces per-client or per-endpoint quotas (100 req/min for free tier, 10K for paid) using token buckets or sliding windows</li>
+   <li><strong>SSL termination</strong> — decrypts HTTPS at the gateway; internal traffic between gateway and services can use plain HTTP on a private network</li>
+   <li><strong>Request/response transformation</strong> — rewrites headers, aggregates multiple backend responses into one, or converts between protocols (REST → gRPC)</li>
+   <li><strong>Caching</strong> — returns cached responses for idempotent GET requests, reducing load on backends</li>
+   <li><strong>Logging &amp; observability</strong> — centralises access logs, latency metrics, and traces across every service at a single chokepoint</li>
+  </ul>
+
+  <p><strong>API Gateway vs. Load Balancer:</strong> A load balancer distributes traffic across identical instances of the same service (Layer 4 or Layer 7 routing). An API Gateway operates at Layer 7 and understands application-level semantics — it routes by path, method, and headers; enforces business policies; and can call multiple backends and merge their responses. Many architectures use both: the gateway as the intelligent front door and a load balancer behind it distributing traffic to each service's pool of instances.</p>
+
+  <p><strong>API Gateway vs. Service Mesh:</strong> An API Gateway manages north-south traffic (external clients ↔ backend). A service mesh (Istio, Linkerd) manages east-west traffic (service ↔ service inside the cluster) — handling mutual TLS, retries, circuit breakers, and observability between microservices. Production systems often run both together.</p>
+
+  <p><strong>How rate limiting works inside a gateway:</strong> On each request the gateway increments a counter in a distributed store (Redis) keyed by client ID and time window. If the counter exceeds the limit it returns <code>429 Too Many Requests</code> with a <code>Retry-After</code> header. The token bucket algorithm allows short bursts above the average rate; the sliding window log is more precise but memory-intensive. All gateway instances share the same Redis counter so the limit is globally enforced across the fleet.</p>
+
+  <p><strong>Failure modes and resilience:</strong> The gateway is a potential single point of failure — run multiple instances behind a load balancer. If the gateway itself is overloaded, back-pressure cascades to clients. Use circuit breakers so the gateway stops forwarding to a failing backend and returns a fast error rather than queueing requests indefinitely. Health checks on backend routes let the gateway stop routing to unhealthy pods automatically.</p>
+
+  <p><strong>Real-world API gateway products:</strong> AWS API Gateway (managed, pay-per-call), Kong (open-source, Nginx-based, plugin ecosystem), Apigee (Google Cloud, enterprise), NGINX (self-managed reverse proxy + gateway features), Envoy (programmatic, used by Istio), and Azure API Management. Choosing between them is mostly a build-vs-buy and cloud-vendor decision rather than a technical one — the patterns above apply to all of them.</p>
+ </section>
+
  <section class="section-block reveal">
  <h2>Interview Q&amp;A</h2>
  <p>Three protocol questions interviewers actually ask — click to reveal strong answers.</p>