first commit

networking.md

@@ -0,0 +1,829 @@
+# Networking Interview Guide For Software Engineers
+
+This guide is meant for interview preparation, not just memorization. The goal is to help you explain how traffic moves through systems, why protocols were designed the way they were, and what tradeoffs show up in production.
+
+## How To Study Networking For Interviews
+
+Treat networking as three linked layers of understanding:
+
+1. Protocol model: what each layer is responsible for.
+2. Request lifecycle: what happens from client to server and back.
+3. Production systems: what breaks, what gets cached, what gets retried, and what gets secured.
+
+If you can answer all three for a topic, you usually understand it well enough for interviews.
+
+## Big Picture: What Happens When You Open A URL?
+
+When a browser requests `https://api.example.com/users`, a lot happens under the hood:
+
+1. The browser parses the URL and extracts the scheme, hostname, path, and port.
+2. DNS resolves `api.example.com` to an IP address.
+3. The client decides where to send the packet, usually to a default gateway if the server is outside the local subnet.
+4. A TCP connection is established to the server, often on port `443`.
+5. A TLS handshake happens to create an encrypted session.
+6. The browser sends an HTTP request over that secure connection.
+7. Load balancers, proxies, firewalls, and application servers may inspect or forward the request.
+8. The server sends back an HTTP response.
+9. The browser may cache content, reuse the connection, or make additional requests.
+
+```mermaid
+flowchart LR
+	A[Browser or Client] --> B[DNS Resolver]
+	B --> C[IP Address Returned]
+	C --> D[TCP Handshake]
+	D --> E[TLS Handshake]
+	E --> F[Load Balancer or Reverse Proxy]
+	F --> G[Application Service]
+	G --> H[Database or Cache]
+	H --> G
+	G --> F
+	F --> E
+	E --> A
+```
+
+This single flow touches most of the topics interviewers care about.
+
+## OSI 7-Layer Model
+
+The OSI model is a conceptual framework. Real networks do not literally say "now we are in layer 5," but the model is useful because it separates responsibilities.
+
+| Layer | Name | What It Does | Real Examples |
+| --- | --- | --- | --- |
+| 7 | Application | User-facing network services | HTTP, DNS, SMTP |
+| 6 | Presentation | Data representation, encoding, encryption | TLS, JSON, JPEG |
+| 5 | Session | Session establishment and management | RPC sessions, NetBIOS |
+| 4 | Transport | End-to-end delivery between processes | TCP, UDP |
+| 3 | Network | Routing between networks | IP, ICMP |
+| 2 | Data Link | Delivery within the local network | Ethernet, MAC, ARP |
+| 1 | Physical | Actual electrical, radio, or optical transmission | Cables, Wi-Fi radio |
+
+### How To Explain Each Layer In Practice
+
+#### Layer 7: Application
+
+This is where application protocols live. If someone says "HTTP request," they are talking about an application-layer protocol. DNS also lives here because it provides a service used by applications.
+
+Interview angle: if an API returns `404`, `500`, or malformed JSON, that is usually an application-layer issue, not a routing issue.
+
+#### Layer 6: Presentation
+
+This layer is about representation. Encryption, compression, and serialization belong here conceptually. In the real world, TLS is often described here because it transforms readable data into encrypted bytes.
+
+Interview angle: when asked why HTTPS exists, explain that application data is wrapped in TLS before it is sent on the transport connection.
+
+#### Layer 5: Session
+
+The session layer is less visible in day-to-day backend work, but the idea still matters. It manages ongoing communication state: establishing sessions, keeping them alive, resuming them, and closing them.
+
+In modern systems, session responsibilities are often spread across libraries and protocols rather than called out separately.
+
+#### Layer 4: Transport
+
+This is where TCP and UDP live. The transport layer gives process-to-process communication, meaning it is not just machine A to machine B, but application process on port X to process on port Y.
+
+Interview angle: if packets arrive but the application still times out, transport details like retransmissions, congestion, socket backlog, or connection exhaustion might matter.
+
+#### Layer 3: Network
+
+This layer is responsible for logical addressing and routing. IP addresses live here. Routers examine layer 3 information to move packets across networks.
+
+Interview angle: if two services are in different networks or subnets, layer 3 determines how traffic gets routed between them.
+
+#### Layer 2: Data Link
+
+This is communication on the local link. Devices here care about MAC addresses. Switches mainly operate here. ARP maps IP addresses to MAC addresses on IPv4 local networks.
+
+Interview angle: when traffic stays inside a LAN, layer 2 behavior matters. When traffic leaves the LAN, a router is usually involved.
+
+#### Layer 1: Physical
+
+The physical layer is the raw transmission medium. It carries bits as electrical signals, light, or radio waves.
+
+Interview angle: higher-level developers do not work here much, but it explains why distance, cable quality, radio interference, and bandwidth constraints are real.
+
+### Encapsulation
+
+As data moves down the stack, each layer adds its own header.
+
+```mermaid
+flowchart TD
+	A[Application Data] --> B[Transport Segment: TCP or UDP Header + Data]
+	B --> C[Network Packet: IP Header + Segment]
+	C --> D[Data Link Frame: MAC Header + Packet]
+	D --> E[Bits On Wire or Air]
+```
+
+Interview answer worth memorizing: each lower layer treats the entire payload from the layer above as data.
+
+## TCP/IP Model
+
+The TCP/IP model is more practical and maps better to the Internet.
+
+| TCP/IP Layer | Rough OSI Mapping | Purpose |
+| --- | --- | --- |
+| Application | OSI 5, 6, 7 | User-visible protocols and data formats |
+| Transport | OSI 4 | End-to-end process communication |
+| Internet | OSI 3 | Routing with IP |
+| Link or Network Access | OSI 1, 2 | Local network delivery |
+
+```mermaid
+flowchart LR
+	A[OSI 7 Application] --> T1[TCP/IP Application]
+	B[OSI 6 Presentation] --> T1
+	C[OSI 5 Session] --> T1
+	D[OSI 4 Transport] --> T2[TCP/IP Transport]
+	E[OSI 3 Network] --> T3[TCP/IP Internet]
+	F[OSI 2 Data Link] --> T4[TCP/IP Link]
+	G[OSI 1 Physical] --> T4
+```
+
+### Why Interviewers Ask About Both Models
+
+They want to know whether you can:
+
+1. Use OSI for reasoning and categorization.
+2. Use TCP/IP for real Internet systems.
+3. Explain where a specific technology belongs.
+
+If asked which model is more "real," say TCP/IP. If asked which model is more useful for teaching, say OSI is often better.
+
+## TCP Vs UDP
+
+This is one of the most common interview topics because it is about tradeoffs.
+
+| Property | TCP | UDP |
+| --- | --- | --- |
+| Connection model | Connection-oriented | Connectionless |
+| Reliability | Reliable delivery with retransmission | No built-in reliability |
+| Ordering | Preserves order | No guaranteed order |
+| Flow control | Yes | No |
+| Congestion control | Yes | No built-in congestion control |
+| Overhead | Higher | Lower |
+| Typical use cases | Web, APIs, databases, SSH | DNS, streaming, gaming, VoIP |
+
+### TCP
+
+TCP provides a reliable byte stream. That means the application reads a stream of bytes, not individual packets. TCP handles:
+
+1. Three-way handshake for connection setup.
+2. Sequence numbers for ordering.
+3. Acknowledgments for successful receipt.
+4. Retransmission of lost segments.
+5. Flow control so the receiver is not overwhelmed.
+6. Congestion control so the network is not flooded.
+
+Three-way handshake:
+
+```mermaid
+sequenceDiagram
+	participant C as Client
+	participant S as Server
+	C->>S: SYN
+	S->>C: SYN-ACK
+	C->>S: ACK
+```
+
+Key point: TCP is reliable, but not magical. It can still time out, stall, or back off under congestion.
+
+### UDP
+
+UDP is a lightweight datagram protocol. It sends discrete messages with minimal built-in guarantees. That makes it faster in some cases, but the application must tolerate loss, duplication, or reordering.
+
+Real-world point: many modern protocols use UDP because they want low latency and implement reliability selectively at the application layer. QUIC is the best modern example.
+
+### Interview-Ready Tradeoff
+
+If asked "Why not always use UDP because it is faster?" the right answer is that many applications need reliable ordered delivery, and reimplementing all of TCP behavior in every application would be complex and error-prone.
+
+If asked "Why not always use TCP?" the answer is that strict ordering and retransmission can increase latency, which is a bad fit for real-time media or interactive gaming.
+
+## Ports, Sockets, And Connections
+
+### Ports
+
+A port identifies a process or service on a host. The IP address identifies the machine, and the port identifies which application on that machine should receive the traffic.
+
+Common well-known ports:
+
+| Port | Protocol / Service |
+| --- | --- |
+| 20/21 | FTP |
+| 22 | SSH |
+| 25 | SMTP |
+| 53 | DNS |
+| 80 | HTTP |
+| 123 | NTP |
+| 143 | IMAP |
+| 443 | HTTPS |
+| 3306 | MySQL |
+| 5432 | PostgreSQL |
+
+### Sockets
+
+A socket is an endpoint for communication. In practice, people often use the term to mean the OS abstraction used by programs to send and receive network data.
+
+For a TCP connection, it is often identified by a 4-tuple:
+
+1. Source IP
+2. Source port
+3. Destination IP
+4. Destination port
+
+That is how a server can support many simultaneous client connections on the same listening port.
+
+### Connections
+
+TCP has connections. UDP does not require a connected session in the same sense, even though programming APIs sometimes let you call `connect()` on a UDP socket for convenience.
+
+Interview angle: if a server is "listening on port 443," that means it has a listening socket waiting for new connections. After accept, each client gets a separate established connection.
+
+## IP Addressing
+
+IP addresses identify network interfaces in an IP network. They are logical addresses, not hardware addresses.
+
+### IPv4
+
+IPv4 uses 32-bit addresses, usually written as four decimal octets, such as `192.168.1.10`.
+
+Important private IPv4 ranges:
+
+| Range | Purpose |
+| --- | --- |
+| 10.0.0.0/8 | Private network |
+| 172.16.0.0/12 | Private network |
+| 192.168.0.0/16 | Private network |
+| 127.0.0.0/8 | Loopback |
+
+Why private IPs matter: devices with private IPs are not directly routable on the public Internet. They usually reach the Internet through NAT.
+
+### IPv6
+
+IPv6 uses 128-bit addresses, written in hexadecimal, such as `2001:0db8:85a3:0000:0000:8a2e:0370:7334`.
+
+Benefits of IPv6:
+
+1. Vast address space.
+2. Reduced need for NAT.
+3. Cleaner support for auto-configuration and modern routing.
+4. Better long-term scalability.
+
+Compressed IPv6 notation removes leading zeros and can shorten one run of zeros with `::`.
+
+Example:
+
+`2001:0db8:0000:0000:0000:ff00:0042:8329`
+
+can become:
+
+`2001:db8::ff00:42:8329`
+
+### Subnetting Basics
+
+Subnetting divides a network into smaller networks. CIDR notation tells you how many bits belong to the network prefix.
+
+Examples:
+
+1. `/24` means 24 bits are network bits, leaving 8 bits for hosts.
+2. `192.168.1.0/24` covers `192.168.1.0` through `192.168.1.255`.
+3. A `/24` usually gives 256 total addresses, though usable host counts depend on context.
+
+Quick mental model:
+
+| CIDR | Total Addresses | Common Use |
+| --- | --- | --- |
+| /24 | 256 | Small subnet |
+| /25 | 128 | Split a /24 into two |
+| /26 | 64 | Smaller service segment |
+| /32 | 1 | Single host route |
+
+Real-world interview point: subnetting is about grouping addresses for routing and isolation, not just address counting.
+
+### Default Gateway
+
+If a host wants to reach an IP outside its local subnet, it sends traffic to the default gateway, which is usually a router.
+
+This is a common practical question: "How does a machine know whether to send directly or to the router?" It compares the destination IP against its subnet mask.
+
+## DNS
+
+DNS maps human-friendly names to machine-usable records.
+
+Common record types:
+
+| Record | Purpose |
+| --- | --- |
+| A | Hostname to IPv4 |
+| AAAA | Hostname to IPv6 |
+| CNAME | Alias to another name |
+| MX | Mail server |
+| TXT | Arbitrary text, verification, SPF, DKIM |
+| NS | Authoritative name server |
+
+### DNS Resolution Flow
+
+```mermaid
+sequenceDiagram
+	participant U as User Device
+	participant R as Recursive Resolver
+	participant Root as Root DNS
+	participant TLD as TLD Server
+	participant Auth as Authoritative DNS
+	U->>R: Query api.example.com
+	R->>Root: Where is .com?
+	Root->>R: Ask .com TLD
+	R->>TLD: Where is example.com?
+	TLD->>R: Ask authoritative server
+	R->>Auth: Where is api.example.com?
+	Auth->>R: A or AAAA record
+	R->>U: Cached answer returned
+```
+
+### Important Interview Points About DNS
+
+1. DNS is hierarchical and distributed.
+2. Resolvers cache answers for performance.
+3. DNS is not just one server; it is a chain of delegated authority.
+4. DNS can fail due to bad records, TTL delays, resolver issues, or propagation lag.
+
+### TTL
+
+TTL, or time to live, tells resolvers how long they may cache a record. A low TTL makes changes propagate faster but increases DNS lookup load. A high TTL reduces lookup traffic but slows rollout changes.
+
+### Practical Scenario
+
+If a service moves to a new IP and some users still hit the old server, DNS caching is one of the first suspects.
+
+## HTTP Vs HTTPS
+
+HTTP is an application protocol for request-response communication. HTTPS is HTTP carried over TLS, which provides encryption, integrity, and server authentication.
+
+| Feature | HTTP | HTTPS |
+| --- | --- | --- |
+| Encryption | No | Yes, via TLS |
+| Integrity | Weak, data can be modified in transit | Protected by TLS |
+| Authentication | No built-in server identity | Certificates authenticate server identity |
+| Default Port | 80 | 443 |
+
+### Why HTTPS Matters
+
+Without HTTPS, anyone on the path can potentially read or modify traffic. That includes credentials, tokens, cookies, and application data.
+
+With HTTPS:
+
+1. The client verifies the server certificate.
+2. A secure session key is negotiated.
+3. Data is encrypted in transit.
+4. Tampering becomes detectable.
+
+### Important Clarification
+
+HTTPS does not hide everything. Observers may still see:
+
+1. Destination IP address.
+2. The fact that a TLS connection exists.
+3. Timing and traffic volume.
+4. In some cases, hostname metadata depending on protocol features and environment.
+
+### HTTP Methods
+
+Common methods and their intent:
+
+| Method | Typical Meaning |
+| --- | --- |
+| GET | Read resource |
+| POST | Create or trigger processing |
+| PUT | Replace resource |
+| PATCH | Partially update resource |
+| DELETE | Remove resource |
+
+### Status Codes Worth Knowing
+
+| Range | Meaning |
+| --- | --- |
+| 1xx | Informational |
+| 2xx | Success |
+| 3xx | Redirection |
+| 4xx | Client error |
+| 5xx | Server error |
+
+Commonly discussed codes: `200`, `201`, `204`, `301`, `302`, `304`, `400`, `401`, `403`, `404`, `409`, `429`, `500`, `502`, `503`, `504`.
+
+### Keep-Alive And Connection Reuse
+
+Opening a new TCP and TLS session for every request is expensive. Modern clients reuse connections when possible. This reduces handshake overhead and latency.
+
+### HTTP/1.1, HTTP/2, And HTTP/3
+
+You do not always need deep protocol internals for interviews, but these are worth knowing:
+
+1. HTTP/1.1 commonly uses persistent connections but has more request multiplexing limitations.
+2. HTTP/2 multiplexes streams over one TCP connection, reducing some head-of-line issues at the HTTP layer.
+3. HTTP/3 runs over QUIC on UDP, improving connection setup and transport behavior.
+
+## SSL/TLS Basics
+
+Strictly speaking, SSL is old and obsolete; modern systems use TLS. In interviews, people still say "SSL certificate" informally, but the actual protocol is TLS.
+
+### What TLS Provides
+
+1. Confidentiality: traffic is encrypted.
+2. Integrity: tampering is detectable.
+3. Authentication: the client can verify the server's identity.
+
+### Simplified TLS Handshake
+
+```mermaid
+sequenceDiagram
+	participant C as Client
+	participant S as Server
+	C->>S: ClientHello
+	S->>C: ServerHello + Certificate
+	C->>S: Key Exchange Material
+	Note over C,S: Shared session keys derived
+	C->>S: Encrypted HTTP request
+	S->>C: Encrypted HTTP response
+```
+
+### Certificates
+
+A certificate binds a public key to a domain identity. Certificate authorities, or CAs, sign certificates so clients can trust them.
+
+If a certificate is expired, signed by an untrusted CA, or does not match the hostname, clients will reject or warn about the connection.
+
+### Interview Pitfall
+
+TLS secures data in transit, not data at rest. Encrypting database traffic with TLS does not automatically encrypt the database files on disk.
+
+## REST APIs
+
+REST is an architectural style, not a wire protocol. It usually rides on HTTP, but the important idea is resource-oriented design and stateless client-server interaction.
+
+### Core REST Ideas
+
+1. Resources are identified by URLs.
+2. Standard HTTP methods express intent.
+3. Requests should be stateless, meaning the server should not rely on hidden per-client session state for each call.
+4. Representations like JSON are sent over HTTP.
+5. Caching can improve scalability.
+
+### Good REST Thinking
+
+Prefer resource-based endpoints like:
+
+`GET /users/123`
+
+instead of action-heavy endpoints like:
+
+`POST /getUserById`
+
+That said, real APIs often mix purity with practicality.
+
+### Idempotency
+
+This topic comes up often.
+
+An operation is idempotent if doing it multiple times has the same effect as doing it once.
+
+1. `GET` should be idempotent.
+2. `PUT` is usually designed to be idempotent.
+3. `DELETE` is usually considered idempotent if repeated deletes do not further change state.
+4. `POST` is not usually idempotent.
+
+Why it matters: retries are common in distributed systems. Idempotent operations are safer to retry.
+
+### Authentication And Authorization In APIs
+
+REST itself does not define auth. Real systems commonly use:
+
+1. Bearer tokens
+2. API keys
+3. Session cookies
+4. OAuth flows
+
+Know the difference:
+
+1. Authentication answers who you are.
+2. Authorization answers what you are allowed to do.
+
+## Load Balancers, Proxies, And Gateways
+
+These terms are related but not interchangeable.
+
+### Load Balancer
+
+A load balancer distributes traffic across multiple backend servers.
+
+Goals:
+
+1. Higher availability.
+2. Better scalability.
+3. Health-based routing.
+4. Sometimes TLS termination.
+
+Two common types:
+
+| Type | Operates Mainly At | Example Decisions |
+| --- | --- | --- |
+| Layer 4 LB | Transport | Route by IP and port |
+| Layer 7 LB | Application | Route by host, path, headers |
+
+Practical example: a layer 7 load balancer can send `/images/*` to one service and `/api/*` to another.
+
+### Forward Proxy
+
+A forward proxy sits between client and Internet. Clients intentionally send requests to it.
+
+Uses:
+
+1. Outbound filtering.
+2. Privacy or identity masking.
+3. Shared caching.
+4. Corporate network control.
+
+### Reverse Proxy
+
+A reverse proxy sits in front of servers. Clients think they are talking to the server directly.
+
+Uses:
+
+1. TLS termination.
+2. Load balancing.
+3. Caching.
+4. Compression.
+5. Authentication integration.
+6. Hiding internal services.
+
+Nginx and Envoy are common examples.
+
+### Gateway
+
+A gateway is a boundary device or service that connects different networks or different protocol domains.
+
+Two meanings show up often in interviews:
+
+1. Network gateway: the next hop that lets a host reach destinations outside its local subnet. This is what "default gateway" usually means.
+2. Application gateway: a service that sits at the edge of an application boundary and manages incoming traffic, translation, policy, or routing.
+
+The common idea is controlled passage between one domain and another.
+
+### API Gateway
+
+An API gateway is a specialized reverse proxy for APIs. It can do routing, auth, rate limiting, request transformation, observability, and aggregation.
+
+Interview distinction: not every reverse proxy is an API gateway, but most API gateways behave like advanced reverse proxies.
+
+```mermaid
+flowchart LR
+	A[Clients] --> B[Load Balancer]
+	B --> C[Reverse Proxy or API Gateway]
+	C --> D[Service A]
+	C --> E[Service B]
+	C --> F[Service C]
+```
+
+## Firewalls And Security Basics
+
+A firewall filters traffic according to rules.
+
+### Types Of Firewalls
+
+1. Packet-filtering or stateless firewalls inspect packets individually.
+2. Stateful firewalls track connection state and make smarter decisions.
+3. Web application firewalls, or WAFs, inspect HTTP traffic for application-layer attacks.
+
+### Common Security Concepts
+
+1. Least privilege: allow only what is needed.
+2. Network segmentation: isolate systems by trust boundary.
+3. Ingress rules: who can reach a service.
+4. Egress rules: where a service can send traffic.
+5. Rate limiting: reduce abuse and protect capacity.
+6. DDoS mitigation: absorb or filter massive traffic floods.
+
+### Examples Of Real Risks
+
+1. Exposing a database port to the public Internet.
+2. Allowing unrestricted outbound traffic from sensitive workloads.
+3. Trusting internal traffic too much.
+4. Forgetting to rotate certificates or credentials.
+
+## CDN, Caching, And Latency
+
+### CDN
+
+A content delivery network caches content at edge locations closer to users.
+
+Benefits:
+
+1. Lower latency.
+2. Reduced origin load.
+3. Better global performance.
+4. Improved resilience for static content.
+
+Typical fit: images, videos, JS bundles, CSS, downloads, and cacheable API responses.
+
+### Caching
+
+Caching means storing a response closer to where it will be reused.
+
+Common cache locations:
+
+1. Browser cache.
+2. CDN edge cache.
+3. Reverse proxy cache.
+4. Application cache like Redis.
+5. Database page cache.
+
+### Cache Concepts Worth Knowing
+
+1. Cache hit: request served from cache.
+2. Cache miss: request must go to origin.
+3. TTL: how long data stays valid.
+4. Eviction: removal policy such as LRU.
+5. Staleness: cached data may be out of date.
+6. Invalidation: explicitly removing outdated cache entries.
+
+### HTTP Caching Headers
+
+Useful headers to know:
+
+1. `Cache-Control`
+2. `ETag`
+3. `Last-Modified`
+4. `Expires`
+
+Interview point: cache invalidation is hard because you are trading correctness, freshness, and performance.
+
+### Latency Breakdown
+
+Latency is not one thing. It is the sum of multiple delays:
+
+1. DNS lookup time.
+2. TCP handshake time.
+3. TLS handshake time.
+4. Network propagation time.
+5. Queuing delay in devices.
+6. Server processing time.
+7. Response transfer time.
+
+```mermaid
+flowchart LR
+	A[User Click] --> B[DNS]
+	B --> C[TCP]
+	C --> D[TLS]
+	D --> E[Request Transit]
+	E --> F[Server Processing]
+	F --> G[Response Transit]
+	G --> H[Rendering or Client Work]
+```
+
+### Throughput Vs Latency
+
+Throughput is how much data or how many requests you can process over time. Latency is how long a single request takes. You can improve one without improving the other.
+
+Example: batching work may improve throughput but worsen latency for individual requests.
+
+## Practical Real-World Scenarios
+
+### Scenario 1: A Website Feels Slow For Users Far From The Server
+
+Possible causes:
+
+1. High round-trip time because of geography.
+2. Too many sequential requests.
+3. No CDN for static assets.
+4. Repeated TCP and TLS handshakes due to poor connection reuse.
+5. Cache misses at multiple layers.
+
+Good interview answer: discuss CDN, caching, compression, connection reuse, reducing chattiness, and serving content from closer regions.
+
+### Scenario 2: Service Works By IP But Not By Domain Name
+
+Likely DNS issue.
+
+Check:
+
+1. DNS record correctness.
+2. TTL and propagation delay.
+3. Resolver cache.
+4. Split-horizon DNS or internal DNS differences.
+5. Wrong CNAME chain or stale record.
+
+### Scenario 3: HTTPS Certificate Errors After Deployment
+
+Possible causes:
+
+1. Expired certificate.
+2. Hostname mismatch.
+3. Missing intermediate certificate.
+4. Clock skew on client or server.
+5. TLS terminated at the wrong layer with the wrong cert.
+
+### Scenario 4: Requests Time Out Intermittently
+
+Possible causes:
+
+1. Packet loss and TCP retransmissions.
+2. Load balancer health check problems.
+3. Connection pool exhaustion.
+4. Slow downstream dependencies.
+5. Firewall or security group rules dropping traffic.
+6. DNS flapping between healthy and unhealthy endpoints.
+
+### Scenario 5: API Returns `502 Bad Gateway`
+
+This usually means a gateway or proxy could not get a valid response from the upstream server.
+
+Good debugging path:
+
+1. Check reverse proxy or load balancer logs.
+2. Check upstream health.
+3. Check timeouts and connection resets.
+4. Check TLS settings between proxy and upstream.
+
+## Common Interview Questions And Strong Answer Directions
+
+### What Is The Difference Between OSI And TCP/IP?
+
+Strong answer: OSI is a conceptual 7-layer model used for understanding network responsibilities. TCP/IP is the practical model used by the Internet. OSI is better for teaching, TCP/IP is closer to real implementation.
+
+### Explain TCP Vs UDP
+
+Strong answer: TCP is connection-oriented and provides reliable ordered delivery with retransmissions and congestion control. UDP is connectionless with lower overhead and no built-in reliability, which makes it useful for latency-sensitive workloads.
+
+### Why Is HTTPS More Secure Than HTTP?
+
+Strong answer: HTTPS is HTTP over TLS. TLS encrypts traffic, verifies server identity through certificates, and protects integrity so attackers cannot silently tamper with data in transit.
+
+### What Happens When You Enter A URL In The Browser?
+
+Strong answer should mention DNS lookup, routing, TCP handshake, TLS handshake for HTTPS, HTTP request/response, load balancers or proxies, server processing, and caching.
+
+### What Is DNS And Why Is It Needed?
+
+Strong answer: DNS is a distributed hierarchical naming system that maps domain names to resource records like IP addresses. It lets humans use names while systems use addresses.
+
+### What Is A Socket?
+
+Strong answer: a socket is an OS-level communication endpoint. For TCP connections, each connection can be identified by source IP, source port, destination IP, and destination port.
+
+### What Is Subnetting?
+
+Strong answer: subnetting divides an address space into smaller networks using a prefix length. It helps with routing, isolation, and efficient address management.
+
+### What Is The Difference Between A Load Balancer And A Reverse Proxy?
+
+Strong answer: a load balancer's primary job is distributing traffic across backends. A reverse proxy sits in front of servers and can also do caching, TLS termination, routing, or auth. In practice, one component can do both.
+
+### Why Use A CDN?
+
+Strong answer: CDNs reduce latency by serving cacheable content from locations closer to users, lower origin load, and improve scalability for global traffic.
+
+### What Causes High Latency?
+
+Strong answer: latency can come from DNS, handshakes, network distance, queuing, packet loss, retransmissions, server processing, and payload size. The right answer is usually a breakdown, not a single cause.
+
+## High-Value Interview Nuances
+
+These points often separate a solid answer from a shallow one:
+
+1. TCP is a byte stream, not a message protocol.
+2. HTTPS secures transport in transit, not application correctness.
+3. DNS is cached heavily, so configuration changes are not always immediate.
+4. Load balancers can work at different layers and may also terminate TLS.
+5. A `401` and a `403` are not the same: unauthenticated versus authenticated but forbidden.
+6. `502`, `503`, and `504` point to different upstream failure modes.
+7. NAT helps conserve IPv4 addresses but changes how addressing works between internal and external networks.
+8. Reliability, ordering, and latency are often tradeoffs, not free features.
+
+## Quick Revision Sheet
+
+If you need a short final-pass checklist before an interview, make sure you can explain:
+
+1. OSI layers and what problems each layer solves.
+2. TCP/IP model and how it maps to OSI.
+3. TCP handshake, reliability, and congestion basics.
+4. UDP tradeoffs and good use cases.
+5. DNS resolution and common records.
+6. IPv4, IPv6, CIDR, and subnet basics.
+7. Difference between HTTP and HTTPS.
+8. TLS purpose, certificates, and handshake basics.
+9. REST principles and idempotency.
+10. Ports, sockets, and connection reuse.
+11. Load balancer, forward proxy, reverse proxy, and gateway differences.
+12. Firewall basics, segmentation, and least privilege.
+13. CDN and caching fundamentals.
+14. How to reason about latency end to end.
+
+## Final Interview Advice
+
+For networking interviews, the strongest answers are usually not the most academic ones. They are the answers that connect protocol theory to production behavior.
+
+A good pattern is:
+
+1. Define the concept clearly.
+2. Explain why it exists.
+3. Describe the tradeoff.
+4. Give a real example of where it matters.
+
+If you can do that consistently, you will sound like an engineer who has worked with real systems rather than someone reciting flashcards.

os/memoryManagement.md

@@ -0,0 +1,921 @@
+# Memory Management for Software Engineering Interviews
+
+Memory management is one of the most important operating-system topics for interviews because it sits at the boundary between hardware reality, kernel policy, language runtime behavior, and application performance. If you build backend systems, work with C++ or Java, debug production latency, or reason about scale, you are already dealing with memory-management tradeoffs even if the kernel hides most of the mechanics.
+
+This guide aims to give you an interview-ready mental model, not just a glossary. The central question is simple:
+
+> How does the operating system make memory appear large, fast, isolated, and safe even though physical RAM is limited, shared, and much slower than the CPU?
+
+## 1. Why Memory Management Exists
+
+An operating system cannot let every process read and write raw physical memory arbitrarily. If it did:
+
+- Any process could corrupt another process.
+- The kernel would have no isolation boundary.
+- Programs would need to know where they are loaded in RAM.
+- Memory would be difficult to share safely.
+- Fragmentation and relocation would become unmanageable.
+
+Memory management exists to solve a few core problems at once:
+
+- Isolation: each process should feel like it owns memory.
+- Protection: invalid or unauthorized accesses should be blocked.
+- Efficiency: RAM should be used well, not wasted.
+- Abstraction: programs should use addresses without caring where data physically lives.
+- Performance: recently used translations and data should be fast to access.
+- Flexibility: the OS should be able to load, move, share, swap, and evict memory as needed.
+
+The big idea is that processes mostly work with logical or virtual addresses, while the operating system and hardware cooperate to map those to physical memory.
+
+## 2. How Memory Works in an Operating System
+
+At a high level, a running process sees a virtual address space. The CPU issues a memory reference like "load from address X". That address is usually not a raw DRAM location. Instead, hardware called the Memory Management Unit (MMU) translates it into a physical address.
+
+The actual flow usually looks like this:
+
+1. A process executes an instruction that references a virtual address.
+2. The CPU checks the TLB, which is a small cache of recent address translations.
+3. If the translation is in the TLB, the CPU quickly gets the physical frame.
+4. If not, hardware or the kernel walks the page tables to find the mapping.
+5. If the page is present in RAM and permissions allow access, the read or write proceeds.
+6. If the page is not present, a page fault occurs and the kernel decides how to handle it.
+
+```mermaid
+flowchart TD
+	A[Instruction references virtual address] --> B{TLB hit?}
+	B -->|Yes| C[Get physical frame quickly]
+	B -->|No| D[Walk page tables]
+	D --> E{Valid present mapping?}
+	E -->|Yes| F[Fill TLB and continue]
+	E -->|No| G[Page fault trap to kernel]
+	G --> H{Can kernel resolve it?}
+	H -->|Yes| I[Load or map page and resume]
+	H -->|No| J[Send error like SIGSEGV or kill process]
+	C --> K[Access cache or DRAM]
+	F --> K
+	I --> K
+```
+
+This explains a lot of interview topics at once:
+
+- Virtual memory gives each process its own address space.
+- Paging breaks memory into fixed-size units.
+- Page tables store the mapping.
+- The TLB makes translation fast.
+- Page faults handle missing pages.
+- Swapping and demand paging allow memory to exceed RAM.
+
+## 3. Logical Address vs Physical Address
+
+This distinction is foundational.
+
+### Logical address
+
+A logical address is the address generated by the CPU from the program's point of view. In modern systems, the term virtual address is usually used in practice, and in interview conversation logical and virtual are often treated as effectively the same thing.
+
+Examples:
+
+- A pointer in C++ points to a virtual address in the process address space.
+- A Java object reference is resolved by the JVM within the process's memory model, but the underlying memory still ultimately lives in virtual memory managed by the OS.
+
+### Physical address
+
+A physical address is the real location in RAM that the memory controller uses.
+
+### Important nuance
+
+Historically, some textbooks distinguish logical from virtual more carefully, especially in segmented systems. For most modern interview contexts, the useful distinction is:
+
+- Program-visible address: logical or virtual
+- Hardware RAM location: physical
+
+### Why the distinction matters
+
+- Protection is enforced on virtual-to-physical translation.
+- Different processes can use the same virtual address values without conflict.
+- The OS can relocate or swap memory without changing application code.
+
+Example:
+
+- Process A may read from virtual address `0x7fff0000`.
+- Process B may also read from virtual address `0x7fff0000`.
+- Those can map to completely different physical frames.
+
+That is why virtual addresses are per-process, while physical addresses are system-wide.
+
+## 4. Address Space
+
+An address space is the range of memory addresses a process can use. More precisely, it is the abstraction of memory visible to that process.
+
+Each process typically gets its own virtual address space containing regions such as:
+
+- Text or code segment
+- Read-only data
+- Global and static data
+- Heap
+- Memory-mapped files
+- Shared libraries
+- Stack
+
+Typical process layout looks like this:
+
+```mermaid
+flowchart TB
+	K[High virtual addresses]
+	S[Stack grows downward]
+	M[Memory-mapped region and shared libraries]
+	H[Heap grows upward]
+	D[Data and BSS]
+	T[Code or text]
+	Z[Low virtual addresses]
+
+	K --> S --> M --> H --> D --> T --> Z
+```
+
+### Interview-level understanding
+
+- The address space is virtual, not raw RAM.
+- The heap and stack are just regions inside that space.
+- Separate processes have separate address spaces.
+- Threads in the same process share the address space but usually have separate stacks.
+
+### 32-bit vs 64-bit intuition
+
+- A 32-bit address space is much smaller and historically made memory pressure and layout constraints more visible.
+- A 64-bit address space is so large that modern systems can use sparse mappings comfortably, which makes techniques like memory-mapped files and guard pages easier to support.
+
+Large virtual address spaces do not mean the machine has that much RAM. They just give the OS a large namespace to manage.
+
+## 5. Memory Allocation Basics
+
+Memory allocation means deciding how memory is assigned to processes, threads, objects, buffers, or pages.
+
+There are several layers of allocation:
+
+- The kernel allocates physical page frames.
+- The kernel maps virtual pages into a process address space.
+- User-space allocators such as `malloc`, `new`, `jemalloc`, or `tcmalloc` manage heap memory inside the process.
+- Language runtimes like the JVM allocate objects within managed heap regions.
+
+### Common allocation categories
+
+#### Static allocation
+
+Memory decided before execution, such as global variables or static storage.
+
+#### Stack allocation
+
+Memory associated with function calls and local variables with automatic lifetime.
+
+#### Heap allocation
+
+Memory requested dynamically at runtime, often with manual or runtime-managed lifetime.
+
+### What `malloc` or `new` really does
+
+Interviewers often ask this because it reveals whether you understand the layers.
+
+At a simplified level:
+
+1. Your program asks the allocator for some bytes.
+2. The allocator tries to satisfy it from existing heap arenas or free lists.
+3. If it needs more memory, it may ask the kernel for additional pages using mechanisms like `brk` or `mmap`.
+4. The kernel updates page tables so those virtual pages belong to the process.
+5. Actual physical pages may still be assigned lazily on first touch, depending on the OS.
+
+So `malloc(1024)` usually does not mean "immediately reserve exactly 1024 physical bytes in RAM". It means "make this memory available in the process's virtual address space and allocator bookkeeping".
+
+## 6. Contiguous vs Non-Contiguous Memory Allocation
+
+This topic is really about how memory is laid out physically or logically for a process.
+
+### Contiguous allocation
+
+In contiguous allocation, a process or region is placed in one continuous block of physical memory.
+
+Advantages:
+
+- Simple bookkeeping
+- Simple address computation
+- Historically easy to implement
+
+Disadvantages:
+
+- Hard to fit variable-sized processes efficiently
+- External fragmentation becomes a serious problem
+- Growing processes is awkward
+- Compaction may be needed
+
+Older memory-management designs used fixed or variable partitions in physical memory, but these approaches did not scale well.
+
+### Non-contiguous allocation
+
+In non-contiguous allocation, a process can occupy multiple separated physical locations.
+
+Examples:
+
+- Paging: memory split into fixed-size pages and frames
+- Segmentation: memory split into logical variable-sized segments
+- Combined designs: segmented paging or paged virtual memory
+
+Advantages:
+
+- Better flexibility
+- Better RAM utilization
+- Easier growth of address spaces
+- Simplifies sharing and protection at smaller granularity
+
+Disadvantages:
+
+- More translation overhead
+- More metadata such as page tables
+- More complex hardware and kernel logic
+
+Modern general-purpose operating systems rely heavily on non-contiguous allocation, especially paging.
+
+## 7. Fragmentation: Internal vs External
+
+Fragmentation means memory is being wasted, but the reason for the waste differs.
+
+### Internal fragmentation
+
+Internal fragmentation happens when allocated memory is larger than what the program actually needs, so wasted space exists inside the allocated unit.
+
+Example:
+
+- If page size is 4 KiB and a process needs 6 KiB, it will use 2 pages, or 8 KiB total.
+- About 2 KiB is unused inside the allocated pages.
+
+This is internal fragmentation because the wasted space is inside the allocated blocks.
+
+### External fragmentation
+
+External fragmentation happens when enough total free memory exists, but it is split into small scattered holes, so a large contiguous request cannot be satisfied.
+
+Example:
+
+- Free blocks of 10 MB, 5 MB, and 20 MB exist.
+- A process requests a contiguous 30 MB block.
+- Total free memory is 35 MB, but there is no single 30 MB region.
+
+This is external fragmentation because the waste exists between allocated regions.
+
+### What causes each one
+
+- Fixed-size allocation units, like pages, tend to create internal fragmentation.
+- Variable-sized contiguous allocation tends to create external fragmentation.
+
+### Interview framing
+
+If asked which fragmentation paging solves, the strong answer is:
+
+> Paging largely eliminates external fragmentation in physical allocation because pages can be placed anywhere, but it still suffers from internal fragmentation at page granularity.
+
+## 8. Virtual Memory
+
+Virtual memory is the abstraction that gives each process a large, private, contiguous-looking address space, regardless of how memory is physically arranged.
+
+The key word is illusion. The OS does not promise that every virtual page is backed by RAM right now. It promises that accesses will either work through translation or be handled through faults, allocation, or process termination.
+
+### What virtual memory provides
+
+- Isolation between processes
+- Protection via access permissions
+- Sparse address spaces
+- The ability to use more virtual memory than physical RAM
+- Efficient sharing of libraries and file mappings
+- Simplified programming model
+
+### Why virtual memory is needed
+
+Without virtual memory:
+
+- Programs would need physical addresses or explicit relocation logic.
+- Different processes could not reuse the same convenient address ranges.
+- Swapping and demand paging would be much harder.
+- Isolation would be weak and unsafe.
+- Shared libraries and memory-mapped files would be more complicated.
+
+### The most important interview insight
+
+Virtual memory is not just about pretending disk is extra RAM. That is too shallow.
+
+It is mainly about:
+
+- address translation,
+- protection,
+- isolation,
+- flexible placement,
+- and loading data only when needed.
+
+Using disk as a backing store is one consequence, not the whole story.
+
+## 9. Paging
+
+Paging is the dominant memory-management technique in modern operating systems.
+
+The idea is simple:
+
+- Divide virtual memory into fixed-size pages.
+- Divide physical memory into fixed-size frames of the same size.
+- Map each virtual page to some physical frame.
+
+If page size is 4 KiB, a virtual address is split into:
+
+- Virtual page number
+- Offset within the page
+
+The offset stays the same during translation. Only the page number changes.
+
+Example:
+
+- Virtual address = page 42, offset 100
+- Page table says page 42 is in frame 900
+- Physical address = frame 900, offset 100
+
+This is why paging avoids needing contiguous physical memory.
+
+### Advantages of paging
+
+- Eliminates most external fragmentation
+- Supports virtual memory naturally
+- Makes sharing and protection easy at page granularity
+- Allows demand paging and swapping
+
+### Costs of paging
+
+- Page-table memory overhead
+- Internal fragmentation inside the last page
+- Translation overhead without a TLB
+- Page faults can be very expensive
+
+## 10. Page Tables
+
+A page table is the data structure that maps virtual pages to physical frames.
+
+Each entry usually stores more than just a frame number. Typical metadata includes:
+
+- Present or valid bit
+- Read or write permissions
+- User or kernel accessibility
+- Dirty bit, meaning page has been modified
+- Accessed or referenced bit
+- Execute-disable bit on supported hardware
+
+### Why page tables matter
+
+They are where isolation and protection become concrete. If the mapping is missing or permissions do not allow access, the CPU traps into the kernel.
+
+### Why page tables can be large
+
+Suppose a process has a large virtual address space and small page size. A flat page table would need an entry for a huge number of possible pages, even if the process only uses a small subset.
+
+That is why real systems use hierarchical or multi-level page tables.
+
+## 11. Multi-Level Paging
+
+Multi-level paging is an optimization for page-table storage.
+
+Instead of one giant page table, the address is broken into multiple index levels. Lower-level tables are allocated only for the parts of the address space actually in use.
+
+```mermaid
+flowchart TD
+	A[Virtual address] --> B[Level 1 index]
+	A --> C[Level 2 index]
+	A --> D[Level 3 index]
+	A --> E[Page offset]
+	B --> F[Top-level page table]
+	F --> G[Next-level table]
+	G --> H[Leaf page table entry]
+	H --> I[Physical frame]
+	E --> J[Physical address uses same offset]
+	I --> J
+```
+
+### Why it helps
+
+- Sparse address spaces do not require allocating a full flat page table.
+- Memory overhead becomes proportional to the used regions of the address space.
+
+### Tradeoff
+
+Walking multiple levels takes more memory accesses on a TLB miss. That is one reason the TLB is so important.
+
+### Real-world example
+
+Modern 64-bit systems such as x86-64 often use four or five levels of paging for large address spaces.
+
+You do not usually need to memorize exact bit splits unless the interviewer is going deep into architecture. What matters is understanding why multi-level paging exists.
+
+## 12. Translation Lookaside Buffer (TLB)
+
+The TLB is a small, very fast cache inside the CPU that stores recent virtual-to-physical translations.
+
+Without a TLB, every memory access could require extra page-table lookups, which would be far too slow.
+
+### Why the TLB matters so much
+
+Every instruction fetch, stack access, heap access, and data read depends on address translation. If translation were always a full page-table walk, memory access would be dramatically slower.
+
+### TLB hit vs miss
+
+- TLB hit: translation found quickly, access continues.
+- TLB miss: hardware or software must walk page tables and possibly populate the TLB.
+
+### Practical implications
+
+- Good locality improves TLB effectiveness.
+- Large page sizes or huge pages can reduce TLB pressure because one entry covers more memory.
+- Context switches can reduce TLB usefulness unless the CPU supports address-space tagging such as ASIDs or PCIDs.
+
+### Backend-system angle
+
+Databases, caches, in-memory analytics engines, and JVM heaps can all suffer when working sets exceed TLB coverage. This is one reason huge pages sometimes help performance-sensitive systems.
+
+## 13. Page Faults
+
+A page fault occurs when a process accesses a virtual page whose translation cannot be completed normally.
+
+That does not automatically mean a bug. Some page faults are expected and legitimate.
+
+### Common reasons for a page fault
+
+- The page has not been loaded yet and must be brought into memory.
+- The page exists but is currently swapped out.
+- The page is marked copy-on-write and needs a private copy on write.
+- The access violates protection, such as writing to a read-only page.
+- The address is invalid and not mapped at all.
+
+```mermaid
+sequenceDiagram
+	participant P as Process
+	participant CPU as CPU or MMU
+	participant K as Kernel
+	participant D as Disk or backing store
+
+	P->>CPU: access virtual page
+	CPU->>K: page fault trap
+	K->>K: inspect page-table entry and permissions
+	alt page can be resolved
+		K->>D: read page if needed
+		D-->>K: page data
+		K->>K: update page table and TLB state
+		K-->>P: resume instruction
+	else invalid or forbidden access
+		K-->>P: send fault signal or terminate
+	end
+```
+
+### Major vs minor page fault
+
+Interviewers sometimes like this distinction.
+
+- Minor page fault: page can be satisfied without disk I/O, for example a copy-on-write mapping or a page already in memory but not mapped into this process yet.
+- Major page fault: servicing the fault requires disk I/O, which is much slower.
+
+### Important nuance
+
+A segmentation fault in Linux is often the user-visible result of an invalid or protection-violating page fault. So page fault is the low-level event; `SIGSEGV` is often the process-level consequence.
+
+## 14. Demand Paging
+
+Demand paging means pages are loaded into memory only when they are actually accessed.
+
+This is one of the biggest reasons virtual memory is efficient. Instead of loading an entire executable or heap eagerly, the OS can load pages lazily.
+
+### Benefits
+
+- Faster program startup
+- Lower RAM usage
+- Only touched pages consume physical memory
+- Large sparse data structures become feasible
+
+### Costs
+
+- First access latency due to page faults
+- Too much lazy loading under pressure can cause many faults
+
+### Real-world examples
+
+- Executable code pages are often loaded on first use.
+- `mmap` of a large file typically does not read the whole file immediately.
+- After `fork`, Linux often uses copy-on-write so parent and child share pages until one writes.
+
+Demand paging is a great interview bridge topic because it connects virtual memory, page tables, page faults, and performance.
+
+## 15. Thrashing
+
+Thrashing happens when the system spends too much time paging pages in and out and too little time doing useful work.
+
+This usually occurs when the active working sets of processes do not fit in available RAM.
+
+### Symptoms
+
+- Very high page fault rate
+- Heavy disk I/O or swap activity
+- CPU utilization may drop because tasks keep waiting on memory
+- Throughput collapses
+- Tail latency becomes terrible
+
+### Why it happens
+
+If a process keeps needing pages that were just evicted, the system enters a destructive loop:
+
+- page needed,
+- page fault,
+- load from disk,
+- evict another needed page,
+- repeat.
+
+### Mitigations
+
+- Add more RAM
+- Reduce multiprogramming level
+- Tune memory limits and eviction behavior
+- Use better locality-friendly algorithms
+- Reduce heap size or working set size
+- Avoid overcommitting memory aggressively
+
+### Practical production example
+
+A Java service in a container with tight memory limits may begin swapping or faulting heavily under burst traffic. Even if CPU looks available, the service becomes slow because it is memory-bound rather than compute-bound.
+
+## 16. Segmentation
+
+Segmentation divides memory into logical variable-sized regions called segments, such as code, data, stack, or heap.
+
+Instead of address = page number + offset, the idea is more like:
+
+- segment number
+- offset within the segment
+
+Each segment has a base and limit.
+
+### Why segmentation is attractive conceptually
+
+- It matches program structure well.
+- Different segments can have different permissions.
+- Sharing logical regions can be natural.
+
+### Main problem
+
+Because segments are variable-sized, segmentation suffers from external fragmentation.
+
+### Modern relevance
+
+Pure segmentation is not the main model in modern general-purpose systems. Modern systems are dominated by paging, though some architectures preserve limited segmentation concepts for special purposes.
+
+Still, segmentation remains important in interviews because it teaches the difference between logical program regions and fixed-size paging units.
+
+## 17. Paging vs Segmentation
+
+This comparison comes up often.
+
+| Aspect | Paging | Segmentation |
+| --- | --- | --- |
+| Unit size | Fixed-size pages | Variable-size segments |
+| View of memory | Physical-management oriented | Logical-program-structure oriented |
+| Fragmentation | Internal fragmentation | External fragmentation |
+| Allocation flexibility | High | Lower under pressure |
+| Protection granularity | Page-based | Segment-based |
+| Modern OS usage | Very common | Limited or combined |
+
+### Strong interview explanation
+
+Paging is better for efficient physical memory management because fixed-size frames are easy to allocate. Segmentation is better for expressing logical program structure, but variable-sized segments fragment memory. That is why modern systems mostly use paging, sometimes with segmentation concepts layered on top or retained for limited architectural roles.
+
+## 18. Swapping
+
+Swapping means moving memory contents between RAM and disk to free physical memory.
+
+Historically, systems sometimes swapped entire processes. Modern systems usually work at page granularity, not by moving whole processes out all at once.
+
+### Why swapping exists
+
+- RAM is finite.
+- Some pages are cold and can be moved out temporarily.
+- This allows the system to keep more virtual memory in use than physical RAM alone would permit.
+
+### Why swapping is dangerous for performance
+
+Disk, even SSD, is far slower than RAM. If hot pages are swapped out and quickly needed again, latency explodes.
+
+### Linux perspective
+
+- Linux can swap anonymous pages under pressure.
+- The kernel also uses the page cache heavily for file-backed data.
+- In containerized systems, excessive swapping often causes severe performance issues, and some deployments disable swap to avoid unpredictable latency.
+
+Swapping is sometimes useful as a safety buffer, but if a latency-sensitive service is actively depending on swap, it is usually already in trouble.
+
+## 19. Stack vs Heap
+
+This is a classic interview topic because it connects language semantics to OS memory layout.
+
+### Stack
+
+The stack is typically:
+
+- Per thread
+- Automatically managed by function call discipline
+- Used for call frames, return addresses, parameters, and many local variables
+- Very fast to allocate and free because it usually just moves the stack pointer
+
+Common properties:
+
+- Lifetime is usually lexical or call-scoped.
+- Size is limited.
+- Deep recursion can cause stack overflow.
+
+### Heap
+
+The heap is typically:
+
+- Shared by threads in the same process
+- Used for dynamically allocated objects
+- Flexible in lifetime and size relative to the stack
+- Managed by allocators or garbage collectors
+
+Common properties:
+
+- Allocation and freeing are more expensive than simple stack-pointer movement.
+- Fragmentation can occur.
+- Bugs such as leaks, double free, or use-after-free often involve heap memory.
+
+### Language examples
+
+#### C++
+
+- Local automatic variable usually lives on the stack.
+- `new` typically allocates on the heap.
+- RAII helps tie resource lifetime to scope.
+
+#### Java
+
+- Each thread has a stack for method frames.
+- Most objects live on the heap managed by the JVM.
+- Some values may be optimized away or scalar-replaced by the JIT, so the old rule "objects are always on the heap" is directionally right for interviews but not perfectly literal.
+
+### Strong interview summary
+
+Stack allocation is fast and structured but limited and scope-bound. Heap allocation is flexible and long-lived but more expensive to manage and more prone to fragmentation and lifetime bugs.
+
+## 20. Memory Leaks and Garbage Collection Basics
+
+Memory leaks are not just a C or C++ problem. They also happen in managed runtimes, just in a different form.
+
+### Memory leak in manual-memory systems
+
+In C or C++, a memory leak usually means allocated memory is no longer needed but can no longer be freed because the program lost track of it.
+
+Examples:
+
+- `malloc` without `free`
+- `new` without `delete`
+- Overwriting the only pointer to an allocated object
+
+### Memory leak in garbage-collected systems
+
+In Java, Go, or other GC languages, a leak usually means memory is still reachable, so the garbage collector cannot reclaim it, even though the application no longer logically needs it.
+
+Examples:
+
+- Static caches that grow forever
+- Listeners never deregistered
+- `ThreadLocal` values retained too long
+- Maps holding references to expired sessions
+
+GC prevents many manual deallocation bugs, but it does not prevent retaining useless objects.
+
+### Garbage collection basics
+
+Most modern garbage collectors are tracing collectors. They start from GC roots, such as stacks, registers, and global references, then mark reachable objects.
+
+Common ideas you should know:
+
+- Mark-sweep: mark reachable objects, reclaim the rest.
+- Mark-compact: reclaim and then compact live objects to reduce fragmentation.
+- Copying collection: copy live objects into a new region, usually efficient for young generations.
+- Generational GC: exploit the fact that most objects die young, so collect young space frequently and old space less often.
+
+### Why GC exists
+
+- Reduces manual memory-management bugs
+- Improves safety and developer productivity
+- Makes high-level languages practical at scale
+
+### Why GC is not free
+
+- Extra CPU overhead
+- Pause times or concurrent collection complexity
+- Write barriers and runtime bookkeeping
+- Potential memory overhead from fragmentation, reserve spaces, or collection strategy
+
+### C++ angle
+
+C++ usually relies on deterministic destruction rather than GC. Strong interview topics include:
+
+- RAII
+- `unique_ptr`
+- `shared_ptr`
+- reference cycles with `shared_ptr`
+- custom allocators and arena allocation
+
+## 21. Real-World Examples from Linux, Java, C++, and Modern Backend Systems
+
+### Linux
+
+#### Copy-on-write after `fork`
+
+When a process forks, Linux does not eagerly copy every page. Parent and child initially share pages as read-only. If one writes, that page faults and the kernel creates a private copy.
+
+This is a classic example of demand paging, page faults, and efficient memory sharing working together.
+
+#### `mmap`
+
+Linux can map files directly into a process address space. Reads and writes can then operate through memory access rather than explicit `read` and `write` calls.
+
+This is important for:
+
+- databases,
+- analytics engines,
+- file-backed caches,
+- zero-copy-style optimizations.
+
+#### Page cache
+
+Linux uses RAM aggressively as a page cache for file data. This is why "free memory" is not the right metric by itself. Used memory may still be reclaimable cache.
+
+### Java
+
+Java memory interview discussion often includes:
+
+- Heap for objects
+- Per-thread stacks
+- Metaspace for class metadata
+- GC generations
+- Stop-the-world pauses vs concurrent collectors
+- Off-heap memory via direct buffers or native libraries
+
+Important practical point:
+
+A Java service can fail from memory pressure even if heap graphs look reasonable because total memory also includes thread stacks, direct buffers, mapped files, metaspace, and native allocations.
+
+### C++
+
+C++ brings memory ownership and lifetime to the front.
+
+Important practical topics:
+
+- stack vs heap allocation,
+- manual memory management,
+- smart pointers,
+- object lifetime,
+- fragmentation under general-purpose allocators,
+- use-after-free,
+- double free,
+- arena allocation for predictable performance.
+
+Many low-latency systems use custom allocators or memory pools to reduce allocator overhead and fragmentation.
+
+### Modern backend systems
+
+#### Containers and cgroups
+
+A process may have plenty of virtual address space but still be killed because the container memory limit is reached. From an interview point of view, that shows the difference between address-space size, RSS, heap size, and actual allowed physical usage.
+
+#### Databases and caches
+
+Databases often care about page size, cache locality, huge pages, and NUMA effects because translation and memory locality directly affect throughput.
+
+#### Managed services
+
+High object churn in a Java service can increase GC frequency. The issue is not just "not enough memory" but often allocation rate, object lifetime distribution, and heap tuning.
+
+#### Native services
+
+A C++ service can show stable CPU but rising latency because of allocator contention, fragmentation, or page faults under memory pressure.
+
+## 22. Common Interview Questions and How to Think About Them
+
+### Why is virtual memory needed?
+
+Strong answer:
+
+Virtual memory provides isolation, protection, flexible placement, sparse address spaces, efficient sharing, and the ability to load or back memory lazily. It is not only about using disk as extra memory.
+
+### What is the difference between a page fault and a segmentation fault?
+
+Strong answer:
+
+A page fault is the low-level event when translation cannot proceed normally. It may be valid and recoverable, like demand paging. A segmentation fault is usually the operating system signal sent to the process when the fault is invalid or violates permissions.
+
+### Why are page tables multi-level?
+
+Strong answer:
+
+A flat page table for a large sparse address space would waste too much memory. Multi-level paging allocates lower-level tables only where needed.
+
+### What problem does the TLB solve?
+
+Strong answer:
+
+It caches recent address translations so each memory access does not require a costly full page-table walk.
+
+### What is the difference between internal and external fragmentation?
+
+Strong answer:
+
+Internal fragmentation is wasted space inside allocated units, like partially used pages. External fragmentation is wasted space between allocated regions, where enough total memory exists but not as one contiguous block.
+
+### Why does paging reduce external fragmentation?
+
+Strong answer:
+
+Because physical frames are fixed-size and pages can be placed anywhere, memory does not need one large contiguous block per process.
+
+### What happens when you call `malloc`?
+
+Strong answer:
+
+Usually the allocator serves the request from an internal free list or arena. If necessary, it requests more pages from the kernel. Physical memory may still be assigned lazily on first access.
+
+### Why can Java still have memory leaks?
+
+Strong answer:
+
+Because GC only frees unreachable objects. If the program keeps references to objects it no longer logically needs, those objects remain reachable and consume memory.
+
+### What is thrashing?
+
+Strong answer:
+
+Thrashing occurs when the system spends most of its time servicing page faults and swapping pages instead of doing useful work, usually because working sets exceed available RAM.
+
+## 23. Practical Scenarios Interviewers Like
+
+### Scenario 1: Service latency spikes under load even though CPU is not maxed
+
+Possible memory-related explanations:
+
+- major page faults,
+- swapping,
+- allocator contention,
+- GC pauses,
+- poor locality causing cache and TLB misses.
+
+### Scenario 2: Container is OOM-killed even though Java heap was below `-Xmx`
+
+Reasoning:
+
+- total process memory includes more than Java heap,
+- thread stacks, direct buffers, metaspace, native libraries, and page cache can all matter,
+- cgroup limit is the real boundary.
+
+### Scenario 3: C++ process memory grows forever
+
+Possibilities:
+
+- actual leak,
+- retained caches,
+- allocator arenas not returned to OS,
+- fragmentation,
+- memory-mapped growth.
+
+### Scenario 4: `fork` is surprisingly cheap on Linux
+
+Reasoning:
+
+- because of copy-on-write, pages are not copied immediately,
+- the kernel mainly duplicates metadata and page-table structures,
+- actual copying happens only on write.
+
+### Scenario 5: Large memory-mapped file is opened instantly
+
+Reasoning:
+
+- `mmap` mainly creates virtual mappings,
+- actual file pages are brought in lazily by page faults on access.
+
+## 24. What to Say in an Interview When You Want to Sound Strong
+
+If you need a compact but impressive explanation, this is a solid framing:
+
+> Modern memory management is built around virtual memory. Each process gets its own virtual address space, and the MMU translates virtual addresses to physical frames using page tables. Paging allows non-contiguous physical allocation, which improves flexibility and largely removes external fragmentation. The TLB makes translation fast, while page faults let the OS load pages lazily through demand paging. Multi-level page tables keep metadata manageable for sparse address spaces. In practice, performance issues often come from page faults, poor locality, TLB pressure, swapping, fragmentation, or runtime-level behaviors like GC and allocator overhead.
+
+That answer ties together theory, hardware, OS behavior, and real production effects.
+
+## 25. Final Mental Model
+
+If you remember only one model, remember this:
+
+- Programs operate in virtual address spaces.
+- The OS and MMU map virtual pages to physical frames.
+- Page tables store mappings and permissions.
+- The TLB caches those mappings for speed.
+- Missing mappings trigger page faults.
+- Demand paging and swapping let the system use RAM lazily and extend apparent memory capacity.
+- Paging trades external fragmentation for manageable internal fragmentation and metadata overhead.
+- Real systems succeed or fail based on locality, working set size, and lifetime management.
+
+Once this clicks, many interview topics stop feeling like disconnected definitions and start feeling like one coherent system.

os/storage.md

@@ -0,0 +1,2 @@
+File Systems
+Disk Scheduling