/wiki / backend-engineering-basics

backend-skills

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[backend-skills]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of backend skills.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Backend Skills

Connections

Related: Index — auto stub for singleton [[backend-skills]] from wiki/backend-engineering-basics/backend-framework.md

Edge Cases & Gotchas

To be written.
To be written.

certificate-authority

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[certificate-authority]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of certificate authority.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Certificate Authority

Connections

Related: Index — auto stub for singleton [[certificate-authority]] from wiki/backend-engineering-basics/tls-handshake.md

Edge Cases & Gotchas

To be written.
To be written.

cookie

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[cookie]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of cookie.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Cookie

Connections

Related: Index — auto stub for singleton [[cookie]] from wiki/backend-engineering-basics/session-authentication.md

Edge Cases & Gotchas

To be written.
To be written.

mongodb

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[mongodb]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of mongodb.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Mongodb

Connections

Related: Index — auto stub for singleton [[mongodb]] from wiki/backend-engineering-basics/nosql-database.md

Edge Cases & Gotchas

To be written.
To be written.

ports

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for broken link [[ports]] — needs human content. This page was referenced 2 times and was missing, so a stub was created to keep the graph connected.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of ports.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Ports

Connections

Related: Index — auto stub, needs proper links to wiki/backend-engineering-basics/dns.md, wiki/backend-engineering-basics/ip-address.md

Edge Cases & Gotchas

To be written.
To be written.

redis

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for broken link [[redis]] — needs human content. This page was referenced 2 times and was missing, so a stub was created to keep the graph connected.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of redis.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Redis

Connections

Related: Index — auto stub, needs proper links to wiki/backend-engineering-basics/nosql-database.md, wiki/backend-engineering-basics/backend-architecture.md

Edge Cases & Gotchas

To be written.
To be written.

sql-query

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[sql-query]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of sql query.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Sql Query

Connections

Related: Index — auto stub for singleton [[sql-query]] from wiki/backend-engineering-basics/sql-database.md

Edge Cases & Gotchas

To be written.
To be written.

websocket

2026-09-19T00:00:00.000Z

The Problem

Auto-created stub for singleton broken link [[websocket]] — referenced once and was missing. Keeps graph connected per AGENTS.md:199.

Formal Definition

Per Wikipedia: “To be written.”

Explanation

Stub — fill with plain language explanation of websocket.

How It Works

To be written.
To be written.
To be written.
To be written.

Visual Explanation

Semantic Network

Key Properties

To be written.

Real-World Example

# TODO: add example for Websocket

Connections

Related: Index — auto stub for singleton [[websocket]] from wiki/backend-engineering-basics/http-protocol.md

Edge Cases & Gotchas

To be written.
To be written.

Backend Engineering Basics -- Map of Content

2026-09-02T00:00:00.000Z

Map of Content for Backend Engineering Basics — 15 concepts. Start here to navigate backend-engineering-basics.

Core Concepts

Backend Architecture — concept
Backend as Program — concept
Backend Framework — concept
curl — concept
DNS — concept
HTTP Protocol — concept
IP Address — concept
JWT Authentication — concept
NoSQL Database — concept
Port — concept
Session Authentication — concept
Socket — concept
SQL Database — concept
TCP Handshake — concept
TLS Handshake — concept

Mechanisms & How Things Work

Pages that explain processes/flows.

Comparisons & Tradeoffs

(No synthesis yet — create via ingest or query —save)

backend-architecture

2026-04-12T00:00:00.000Z

The Problem

How do you structure a production backend system? A single monolithic server handling everything won’t scale, won’t handle failures gracefully, and becomes impossible to maintain. You need a well-structured architecture.

Core Idea

Modern backend architecture typically layers into: Client → API Server → Database → Cache → Background Workers. Each layer has a specific responsibility. This separation allows independent scaling, fault isolation, and maintainability.

How It Works

Client Layer: Front end (web, mobile) makes API requests
API Server Layer: Handles routing, business logic, request validation (Node.js, Python, Java)
Database Layer: Persistent storage for data (PostgreSQL, MongoDB)
Cache Layer: Fast in-memory storage for frequently accessed data (Redis)
Background Workers: Async processing for tasks that don’t need immediate response (email, notifications, data processing)

The API server is the central hub—it receives requests, orchestrates logic, and coordinates with other layers.

Key Properties

Layered architecture separates concerns
Each layer can scale independently
Caching improves performance dramatically
Background workers handle async tasks (don’t block requests)
Reverse proxies (Nginx) often sit in front for TLS termination, load balancing

Visual Explanation

Semantic Network

Connections

Built from: Backend as Program — the API server is a program
Builds into: Server — this architecture runs on server infrastructure
Related: SQL Database — one database layer option
Related: NoSQL Database — another database option
Related: Redis — common cache layer
Related: Backend Framework — provides the API server component

Edge Cases & Gotchas

Network calls between layers add latency
Distributed systems introduce new failure modes
Data consistency across layers is hard (cache invalidation)
Too many layers adds complexity—balance with your scale

backend-as-program

2026-04-12T00:00:00.000Z

The Problem

How do we build systems that can serve multiple clients, process data, and run continuously? Without understanding that backend is fundamentally a program, developers rely on frameworks without understanding what actually happens.

Core Idea

A backend is simply a program running on a server that receives requests, processes logic, talks to databases, and sends responses. It’s not a special machine—it’s software that listens on a network port.

How It Works

Infinite Loop: A backend server runs an infinite loop: wait for request → process request → send response
Port Listening: The program binds to a specific port (e.g., 8080) and waits for incoming connections
Request Processing: When a request arrives, the server parses it, executes business logic, may query databases
Response: The server sends back data in a structured format (typically JSON)
Continuous Operation: Servers run for months or years, handling thousands of requests

The key insight: your laptop can be a server. Running python -m http.server 8000 makes your machine a web server.

Key Properties

Runs continuously (infinite loop)
Listens on a specific port for connections
Processes client requests and returns responses
Can be written in any language (Python, Java, Go, Node.js)
Not a physical machine—a program that can run anywhere

Visual Explanation

Semantic Network

Connections

Built from: Socket — the underlying mechanism that receives connections
Builds into: Server — when this program runs on a machine, it becomes the server
Builds into: Back End — the backend is the execution environment for this program
Contrasts with: Front End — runs on client, not server
Related: Client-Server Model — this program typically plays the server role

Edge Cases & Gotchas

A single server can handle many clients simultaneously because each gets its own socket connection
Without proper error handling, one crashed request shouldn’t crash the entire server
The server must handle concurrent requests—either through threading, async, or event loops

backend-framework

2026-04-12T00:00:00.000Z

The Problem

Writing a web server from scratch (socket binding, HTTP parsing, routing, error handling) is time-consuming and error-prone. Every project would reinvent the same basics. Frameworks automate this.

Core Idea

A backend framework is a library that provides the boilerplate for building web servers: HTTP server, routing, database connectors, middleware, and helpers. They automate the basics so developers focus on business logic. The key insight: frameworks are just abstractions over the fundamentals—if you know the fundamentals, any framework is learnable.

How It Works

HTTP Server: Built-in server (or integrates with one)
Routing: Map URL paths to functions (e.g., /users → getUsers())
Middleware: Chain of functions that process requests (auth, logging, CORS)
Database Integration: Connect to SQL/NoSQL databases with helper libraries
Request/Response Objects: Parsed objects with headers, body, params
Helpers: JSON parsing, validation, templating, sessions

When you write app.get("/users", handler), the framework handles the socket, parses HTTP, calls your handler, formats the response.

Key Properties

Language-specific: Python (Django, FastAPI), JavaScript (Express, NestJS), Java (Spring Boot), Go (Gin), Rust (Actix)
Opinionated (Django) vs unopinionated (Express)
Includes batteries (Django) vs minimal (Express)
Synchronous or asynchronous execution models
Frameworks don’t handle TLS in production—that’s the reverse proxy’s job

Visual Explanation

Semantic Network

Connections

Built from: HTTP Protocol — frameworks parse and handle HTTP
Built from: Socket — frameworks abstract socket handling
Builds into: Backend Architecture — frameworks implement the API server layer
Related: Backend Skills — skills needed beyond just knowing frameworks

Edge Cases & Gotchas

Don’t confuse framework with runtime—Spring Boot runs on JVM, Express on Node.js
Frameworks add abstraction cost—understand what’s happening underneath
Production deployments need reverse proxies (Nginx) for TLS, load balancing
Framework choice affects performance but fundamentals transfer between them

curl

2026-04-12T00:00:00.000Z

The Problem

How do you test backend APIs directly without building a front end? How do you inspect what’s actually sent over the wire? curl provides a CLI interface to speak HTTP directly—essential for backend development and debugging.

Core Idea

curl is a command-line tool that sends HTTP requests and prints the response. It bypasses browsers—you can directly test endpoints, inspect headers, send POST data. It’s the backend developer’s direct connection to the server.

How It Works

Parse URL: curl extracts protocol, domain, port, path from the URL
DNS Lookup: Resolves domain to IP address
Socket Connection: Opens TCP socket to IP:port
TLS Handshake: For HTTPS, establishes encrypted connection
Send Request: Writes raw HTTP request text to socket
Receive Response: Reads response from server and prints to terminal

Example: curl https://example.com sends GET / HTTP/1.1 and prints the HTML response.

Key Properties

CLI tool available on all major operating systems
Supports multiple protocols: HTTP, HTTPS, FTP, etc.
Options: -X (method), -H (headers), -d (body), -v (verbose)
Great for API testing: curl -X POST -H "Content-Type: application/json" -d '{"name":"ani"}' https://api.example.com
-v flag shows full request/response headers and connection details
Does not execute JavaScript like browsers do

Visual Explanation

Semantic Network

Connections

Built from: Socket — curl creates socket connections
Built from: HTTP Protocol — curl sends HTTP requests
Built from: TLS Handshake — curl handles HTTPS automatically
Related: DNS — curl uses DNS to resolve domains
Related: Backend as Program — curl talks to backend servers

Edge Cases & Gotchas

Doesn’t render HTML or execute JavaScript—just shows raw response
Default timeout may be too long for failing servers
Use -L to follow redirects
For complex APIs, tools like Postman may be more convenient than curl

dns

2026-04-12T00:00:00.000Z

The Problem

Humans can’t remember IP addresses (142.250.183.46), but computers need them. Without DNS, we’d have to memorize strings of numbers for every website—a completely unusable internet.

Core Idea

DNS is the phonebook of the internet. It translates human-readable domain names (google.com) into machine-readable IP addresses. When you type a URL, DNS servers look up the corresponding IP and direct your request there.

How It Works

Query: Your browser asks a DNS resolver: “What’s the IP for google.com?”
Resolution: The resolver checks its cache; if not found, it queries root servers, then TLD servers (.com), then authoritative nameservers
Response: The resolver returns the IP address (e.g., 142.250.183.46)
Connection: Your browser now connects to that IP address

This happens in milliseconds. DNS uses caching heavily—once resolved, subsequent requests don’t need to go through the full lookup.

Key Properties

Hierarchical distributed database
Caches results to speed up repeated lookups
Multiple record types: A (IPv4), AAAA (IPv6), CNAME (alias), MX (mail), TXT
Operates on UDP port 53 (typically)
Anycast allows multiple servers to serve the same domain from different locations

Visual Explanation

Semantic Network

Connections

Built from: IP Address — DNS resolves to IP addresses
Builds into: HTTP — HTTP requests need an IP, which DNS provides
Builds into: DNS Lookup — DNS lookup is the full resolution process
Related: Port — IP + port identifies the final destination
Related: DNS Cache — caching speeds up DNS resolution
Related: Recursive DNS — does the heavy lifting for clients
Contrasts with: Circuit Switching — DNS is packet-based, not circuit-based

Edge Cases & Gotchas

DNS poisoning/caching attacks can redirect users to malicious sites
DNS can be slow for first-time lookups—that’s why browsers cache aggressively
Changing DNS records can take time to propagate (TTL)
Some networks block certain DNS queries

http-protocol

2026-04-12T00:00:00.000Z

The Problem

Without a standardized protocol, every client and server would need custom communication logic. Each request would need to define how to format data, indicate success/failure, handle errors. HTTP provides this shared language so any client can talk to any server.

Core Idea

HTTP (Hypertext Transfer Protocol) is a text-based request-response protocol that defines how clients and servers exchange messages. It operates over TCP (or TLS for HTTPS), with a simple structure: method, path, headers, optional body. The server processes the request and returns a status code, headers, and body.

How It Works

Request Line: Client sends “GET /users HTTP/1.1” specifying method, path, protocol version
Headers: Additional metadata like Host, Content-Type, Authorization
Body: For POST/PUT requests, data goes in the body (JSON, form data)
Processing: Server parses the request, runs logic, possibly queries database
Response: Server sends “HTTP/1.1 200 OK” with status code, headers, body

HTTP is stateless—each request is independent. Servers don’t remember previous requests from the same client.

Key Properties

Text-based message format (HTTP/1.1), binary in HTTP/2
Methods: GET (fetch), POST (create), PUT (update), DELETE (delete), PATCH (partial update)
Status codes: 2xx (success), 3xx (redirect), 4xx (client error), 5xx (server error)
Headers provide metadata: Content-Type, Authorization, Cache-Control
Runs over TCP (port 80) or TLS (port 443 for HTTPS)

Visual Explanation

Semantic Network

Connections

Built from: Socket — HTTP runs over TCP socket connections
Built from: TCP Handshake — TCP establishes reliable connection first
Builds into: API — REST APIs use HTTP as the communication protocol
Contrasts with: WebSocket — WebSocket is bidirectional, HTTP is request-response
Related: HTTPS — HTTP over TLS encryption
Related: HTTP Methods — specific operations defined in HTTP
Related: HTTP Status Codes — response outcome codes

Edge Cases & Gotchas

HTTP is text-based—binary data must be encoded (Base64) or use multipart
No inherent state—every request must re-authenticate or send session tokens
Headers have size limits, bodies can be arbitrarily large
Without keep-alive, every request needs a new TCP connection (slow)

ip-address

2026-04-12T00:00:00.000Z

The Problem

How do we uniquely identify a machine on a network? Without IP addresses, computers cannot send data to specific destinations—they wouldn’t know where to deliver packets.

Core Idea

An IP address is a numerical identifier assigned to each device connected to a computer network. It serves as both identification (which machine) and location (how to reach it). Humans use domain names; machines use IP addresses.

How It Works

Allocation: Every device on a network gets a unique IP address—either dynamically assigned (DHCP) or statically configured
Format: IPv4 uses 32-bit addresses (e.g., 142.250.183.46), while IPv6 uses 128-bit addresses for larger networks
Routing: Network routers use IP addresses to forward packets toward their destination
Translation: DNS converts human-readable domain names (google.com) to IP addresses

When you type “google.com”, DNS resolves it to an IP like 142.250.183.46. Your computer then sends packets to that address.

Key Properties

Unique identifier for each device on a network
Used for routing packets to the correct destination
Can be public (internet-accessible) or private (internal network only)
Two versions: IPv4 (32-bit, ~4 billion addresses) and IPv6 (128-bit, vast address space)
Can be static (fixed) or dynamic (changes)

Visual Explanation

Semantic Network

Connections

Built from: Packet Switching — IP addresses are used to route packets
Builds into: Socket — a socket combines IP + port to identify a specific program
Related: DNS — translates domain names to IP addresses
Related: Port — works with IP to identify specific programs on a machine
Contrasts with: MAC Address — layer 2 address, unique to network interface hardware

Edge Cases & Gotchas

A single machine can have multiple IP addresses (multiple network interfaces)
Private IP addresses cannot be accessed directly from the internet ( NAT required)
IP addresses can change (dynamic allocation)—that’s why we use domain names
IPv4 address exhaustion led to IPv6 adoption

jwt-authentication

2026-04-12T00:00:00.000Z

The Problem

Sessions require server-side storage and don’t work well across multiple servers. What if you need to scale horizontally without sticky sessions, or authenticate from mobile apps where cookies don’t work? JWT provides a stateless solution.

Core Idea

JWT (JSON Web Token) is a self-contained token that contains user information encoded as JSON, signed cryptographically. Instead of storing sessions in a database, the server embeds user data directly in the token. The client sends the token with each request; the server verifies the signature to trust the data.

How It Works

Login: User submits credentials
Token Creation: Server verifies credentials, creates JWT with user ID and claims, signs with secret/key
Token Sent: Server returns JWT to client (in response body or Authorization header)
Subsequent Requests: Client sends JWT in Authorization header: Bearer <token>
Verification: Server verifies signature, extracts user info, processes request
No Server Storage: Token contains all needed information—no lookup required

JWT has three parts: header (algorithm), payload (claims), signature (verification).

Key Properties

Stateless—no server-side session storage needed
Self-contained—token holds user info and claims
Signed—server can verify authenticity without database lookup
Scalable—any server can verify token, no shared session store needed
Client stores token (localStorage or secure storage)
Popular for APIs, SPAs, mobile apps

Visual Explanation

Semantic Network

Connections

Built from: TLS Handshake — tokens should be sent over HTTPS
Builds into: API — JWT commonly secures REST APIs
Contrasts with: Session Authentication — different auth paradigm
Related: HTTP — JWT sent in Authorization header

Edge Cases & Gotchas

Tokens are immutable—if you need to revoke, you need a blacklist (defeats statelessness)
Tokens in localStorage are vulnerable to XSS
Token size larger than session ID (more bandwidth)
No logout on server—you can only expire tokens on client
Need to handle token refresh (short-lived access + long-lived refresh tokens)

nosql-database

2026-04-12T00:00:00.000Z

The Problem

What if your data doesn’t fit neatly into tables? What if you need to scale horizontally across many servers, or your data structure changes frequently? SQL’s rigid schema becomes a limitation—NoSQL provides flexibility.

Core Idea

NoSQL databases store data in flexible, schema-less formats: documents (JSON-like), key-value pairs, wide-column stores, or graphs. There’s no fixed table structure—each record can have different fields. This makes them ideal for rapidly evolving data models and massive scale.

How It Works

Flexible Schema: Store any JSON-like document without predefined structure
Insertion: Simply push documents with any fields—no ALTER TABLE needed
Querying: Query by any field, though queries can be less powerful than SQL joins
Scaling: Designed for horizontal scaling—add more servers easily
Variants: Document (MongoDB), Key-Value (Redis), Wide-Column (Cassandra), Graph (Neo4j)

Example: A user document might have {name: "ani", followers: 1200} in one record, and {name: "rahul", tags: ["dev", "ai"]} in another.

Key Properties

Flexible/dynamic schema—no rigid table definitions
Horizontal scaling is native—designed for distributed systems
Often sacrifices ACID for performance and scalability (BASE: Basically Available, Soft state, Eventual consistency)
Optimized for specific use cases (key-value lookup, document storage, graph traversal)
Popular: MongoDB, Redis, Cassandra, DynamoDB, Neo4j

Visual Explanation

Semantic Network

Connections

Builds into: Backend as Program — backend programs interact with NoSQL databases
Contrasts with: SQL Database — different data model and trade-offs
Related: Redis — popular key-value NoSQL store (also used for caching)
Related: MongoDB — popular document database

Edge Cases & Gotchas

No foreign keys or joins—data duplication or application-level joins required
Eventual consistency can be confusing (data may not appear immediately)
Less powerful querying than SQL—can’t do complex aggregations easily
Schema-less means no compile-time validation—bugs can slip into production

port

2026-04-12T00:00:00.000Z

The Problem

A single machine runs many services (web server, database, email, SSH). How do network packets know which service they’re meant for? Without ports, all incoming traffic would go to the same destination.

Core Idea

A port is a 16-bit number (0-65535) that identifies a specific service or application on a machine. While IP identifies which machine, port identifies which program on that machine. Together (IP:port), they uniquely identify a network endpoint.

How It Works

Identification: When a server starts a service, it binds to a specific port (e.g., HTTP = 80, HTTPS = 443)
Listening: The server listens on that port for incoming connections
Routing: When packets arrive, the OS uses the port number to forward data to the correct application
Response: The service sends responses back through the same port

Example: connecting to 142.250.183.46:443 means: connect to machine 142.250.183.46, port 443 (HTTPS service).

Key Properties

16-bit number: 0-65535
Well-known ports (0-1023): reserved for standard services (HTTP=80, HTTPS=443, SSH=22, PostgreSQL=5432)
Registered ports (1024-49151): assigned to specific applications
Dynamic ports (49152-65535): used for client-side ephemeral connections
Multiple services can run on one machine if they use different ports

Visual Explanation

Semantic Network

Connections

Built from: IP Address — ports are combined with IP to form a socket
Builds into: Socket — a socket is IP + port
Related: DNS — domain names resolve to IP, then ports route to specific services
Related: Server — servers listen on specific ports
Related: HTTP — typically runs on port 80 (HTTP) or 443 (HTTPS)

Edge Cases & Gotchas

Only one application can bind to a port at a time
Ports below 1024 require root/admin privileges on Unix systems
Firewall rules can block specific ports
Port conflicts cause “address already in use” errors

session-authentication

2026-04-12T00:00:00.000Z

The Problem

HTTP is stateless—each request is independent. How does the server remember you’re logged in after you submit the login form? Without sessions, every request would require re-entering credentials. Sessions solve this by creating persistent authenticated state.

Core Idea

Session authentication works by: user logs in → server creates a session ID → server stores session data → server sends session ID as a cookie → browser sends cookie with every request → server looks up session and knows who you are.

How It Works

Login: User submits credentials (username/password)
Session Creation: Server verifies credentials, creates a session (stores user ID in memory/database)
Cookie: Server sends session ID to browser as a cookie (Set-Cookie header)
Subsequent Requests: Browser automatically sends cookie with each request
Verification: Server looks up session by ID, retrieves user info, processes request
Logout: Server destroys session, browser clears cookie

The session ID is just a random string—the actual user data stays on the server (secure).

Key Properties

Server-side session storage (memory, Redis, database)
Session ID stored in browser cookie (HttpOnly, secure flags for security)
Sessions can expire (timeout) or be explicitly invalidated (logout)
Server can store additional data in session (permissions, preferences)
Classic approach used by traditional web applications

Visual Explanation

Semantic Network

Connections

Built from: HTTP — sessions use HTTP cookies
Builds into: Backend as Program — backend handles session management
Contrasts with: JWT Authentication — different stateless approach
Related: Cookie — the mechanism for storing session ID on client

Edge Cases & Gotchas

Session storage fills memory on server—need external store (Redis) for scaling
Cookies are vulnerable to XSS if not HttpOnly—attacker can steal session ID
CSRF attacks can exploit sessions—need CSRF tokens
Session hijacking—use secure, HttpOnly cookies and consider regenerating IDs

socket

2026-04-12T00:00:00.000Z

The Problem

How do two programs on different machines actually communicate? Without sockets, there’s no way to establish a connection, send data, and receive responses—the foundation of all network communication is missing.

Core Idea

A socket is a communication endpoint between two machines, uniquely identified by the 4-tuple: (client IP, client port, server IP, server port). It’s the OS-managed channel that allows programs to send and receive data over a network.

How It Works

Server Side: Server creates a socket, binds to an IP:port, and listens for connections
Client Side: Client creates a socket and connects to server’s IP:port
Connection: TCP handshake establishes the connection (for TCP sockets)
Communication: Both sides can send() and receive() data through the socket
Termination: Connection closes when either side calls close()

The socket is essentially a file-like interface managed by the OS kernel. You read from it and write to it just like a file.

Key Properties

Unique 4-tuple identifies each connection: (client IP, client port, server IP, server port)
Two main types: TCP (reliable, ordered) and UDP (fast, unreliable)
Sockets have send and receive buffers to handle network timing differences
Server has one listening socket per port, plus one connection socket per client
Everything network-related runs on top of sockets—HTTP, TLS, WebSockets, databases

Visual Explanation

Semantic Network

Connections

Built from: IP Address — IP identifies the machine
Built from: Port — port identifies the program
Built from: MAC Address — final delivery uses MAC on local network
Builds into: TCP Handshake — TCP handshake creates socket connections
Builds into: HTTP — HTTP runs over socket connections
Builds into: TLS Handshake — TLS runs over sockets
Related: Backend as Program — backend programs use sockets to receive requests

Edge Cases & Gotchas

Each client gets a NEW connection socket—server doesn’t reuse the listening socket for data
Socket buffers can overflow if data isn’t consumed fast enough (backpressure)
Network partitions can leave sockets in unclear states—timeouts matter
Non-blocking sockets are used in high-performance servers (Node.js event loop)

sql-database

2026-04-12T00:00:00.000Z

The Problem

How do we store data in a structured, organized way that ensures data integrity, enables complex queries, and maintains relationships between different pieces of information? Flat files can’t handle this—SQL databases provide the solution.

Core Idea

SQL (Structured Query Language) databases store data in rigidly defined tables with rows and columns. Each table has a schema that defines what columns exist and what types they hold. Relationships between tables are defined through foreign keys, enabling joins and complex queries.

How It Works

Schema Definition: You define tables with columns and data types (e.g., users table has id, name, email)
Data Insertion: Insert rows into tables following the schema
Querying: Use SELECT statements to fetch data, with JOINs to combine tables
Relationships: Foreign keys link tables (users.id = orders.user_id)
Transactions: Group multiple operations that must all succeed or all fail together

Example: SELECT * FROM users WHERE name = 'ani' returns all rows from users table matching the condition.

Key Properties

ACID compliant: Atomicity, Consistency, Isolation, Durability
Predefined schema—all data must conform to table structure
Powerful queries with JOINs, aggregations, subqueries
Primary keys, foreign keys enforce relationships and data integrity
Popular: PostgreSQL, MySQL, SQLite, Oracle

Visual Explanation

Semantic Network

Connections

Builds into: API — backends query databases to serve API responses
Builds into: Backend as Program — backend programs interact with databases
Contrasts with: NoSQL Database — different data model and trade-offs
Related: SQL Query — the language used to interact with SQL databases

Edge Cases & Gotchas

Schema changes require migrations (adding columns to production tables is complex)
Horizontal scaling is harder than NoSQL—sharding adds complexity
Complex joins can be slow on large datasets
Object-relational impedance mismatch—mapping objects to tables is work

tcp-handshake

2026-04-12T00:00:00.000Z

The Problem

Before sending any application data, how do two machines ensure they can actually communicate? Networks are unreliable—packets get lost, duplicated, reordered. Without establishing a reliable connection first, data transfer would be chaos.

Core Idea

TCP uses a three-way handshake to establish a reliable connection: Client sends SYN → Server responds with SYN-ACK → Client confirms with ACK. This exchange ensures both sides are ready to send and receive data reliably before any actual data flows.

How It Works

SYN: Client sends SYN (synchronize) with a random sequence number
SYN-ACK: Server acknowledges with SYN-ACK (its own sequence number + acknowledges client’s)
ACK: Client confirms with ACK, completing the handshake
Established: Connection is now open—both sides can send data

This happens before TLS handshake (for HTTPS) and before any HTTP request. It’s the foundation of reliable communication.

Key Properties

Three packets: SYN → SYN-ACK → ACK
Establishes sequence numbers for reliable, ordered delivery
Before this: no guarantee packets will reach
After this: TCP guarantees delivery, ordering, no duplication
Takes 1 RTT (round-trip time) to complete
Part of TCP, not HTTP—HTTP runs on top of TCP

Visual Explanation

Semantic Network

Connections

Built from: Socket — TCP handshake creates socket connections
Built from: ARP Protocol — IP to MAC resolution before TCP
Builds into: TLS Handshake — TLS runs after TCP is established
Builds into: HTTP Protocol — HTTP runs over TCP connections
Builds into: TCP Packet Drop — TCP handles lost packets
Related: IP Address — TCP routes packets to IP addresses

Edge Cases & Gotchas

Handshake adds latency—connection reuse (keep-alive) avoids repeated handshakes
SYN flood attacks exploit the half-open state
TLS 1.3 reduces handshake to 1 round trip (1-RTT) vs 2 in TLS 1.2
UDP doesn’t have handshake—it’s unreliable but faster

tls-handshake

2026-04-12T00:00:00.000Z

The Problem

Without encryption, anyone between client and server can read or modify data (passwords, credit cards, messages). Without authentication, you can’t verify you’re talking to the real server. TLS solves both problems—but how do two machines agree on encryption without an attacker eavesdropping?

Core Idea

TLS (Transport Layer Security) handshake is the negotiation process where client and server agree on encryption methods, exchange keys securely, and verify each other’s identity before any actual data is sent. It’s like two strangers meeting and agreeing on a secret language and verifying IDs before sharing secrets.

How It Works

Client Hello: Client sends supported cipher suites, TLS version, and a random number
Server Hello: Server picks a cipher, sends its certificate, and its own random number
Certificate Verification: Client verifies the server’s certificate against trusted Certificate Authorities (CAs)
Key Exchange: Both derive a shared secret key using Diffie-Hellman or RSA (the key itself is never sent)
Finished: Both confirm the handshake succeeded, switching to encrypted communication

After handshake, all data is encrypted using the agreed-upon cipher (e.g., AES-256-GCM).

Key Properties

Establishes encrypted channel before any application data
Provides server authentication (client knows it’s talking to the real server)
Optionally provides client authentication (mutual TLS)
Uses asymmetric encryption for key exchange, symmetric for data encryption (efficient)
Runs on top of TCP, before HTTP begins

Visual Explanation

Semantic Network

Connections

Built from: Socket — TLS runs over TCP sockets
Built from: TCP Handshake — TCP must be established first
Builds into: HTTPS — HTTPS is HTTP over TLS
Builds into: HSTS — HSTS enforces HTTPS/TLS usage
Related: HTTP — TLS encrypts HTTP communication
Contrasts with: HTTP — plain HTTP has no encryption or authentication
Related: Certificate Authority — CAs sign certificates for server verification

Edge Cases & Gotchas

Expired certificates cause browser warnings
Self-signed certificates work for development but not production
TLS termination usually happens at reverse proxy (Nginx), not at the app
TLS 1.3 is faster (1 round trip vs 2 in TLS 1.2)
Man-in-the-middle attacks are trivial on HTTP, nearly impossible on HTTPS