Tech You Know But Don't Really Understand: What Happens Underneath

The hook

You use them every day. You can name them in a meeting. You might even configure them. But can you explain what actually happens underneath? You use it. You can explain it. But can you explain what happens underneath?

This is the gap that separates "I've heard of it" from "I understand it." Knowing the name is not understanding the technology. So let's take ten everyday systems and look at the mechanism behind the name — the part you rarely have to think about, until it breaks.

The thesis of this article

Every technology in this list exists because it solves a specific problem in a specific way. When you understand the way, the features, the failures, and the scaling behaviour all become predictable instead of mysterious.

Kafka — it isn't a queue that deletes

You know Kafka. But what actually happens when you publish a message? You send OrderCreated to Kafka — and Kafka doesn't simply "store a message."

Kafka is a durable, append-only log. Consumers don't delete; they track their own offset.

Behind the scenes, a single publish travels:

The producer appends to the end of a partition — an ordered, append-only log segment.
Each message receives a monotonically increasing offset within that partition.
The log is persisted and replicated before ack (with acks=all), so it survives broker loss.
Consumers don't delete messages after reading them. They track their own position.

The important part

Because reading never mutates the log, multiple consumers can read the same event independently, at different speeds, and a brand-new service can rewind to offset 0 and rebuild its state from history. That single property — read does not delete — is what fan-out, replay and decoupling all follow from.

Ordering only holds inside a partition, so you key by the entity whose order matters (customer ID, order ID). Beyond a partition there is no global order. That trade-off is the whole shape of Kafka.

Redis — it isn't magically fast

You know Redis is fast. But why? It isn't magic. Redis is fast because the design removes the things that make other datastores slow.

A GET resolves through an in-memory hash table directly to the value — no disk lookup on the hot path.

Data lives primarily in memory. A GET user:123 is a hash-table lookup in RAM, not a disk read.
Single-threaded command execution. No locks, no context-switching overhead, no concurrent mutation races. Commands are atomic and sequential.
Efficient data structures. Strings, hashes, sorted sets and bitmaps are chosen so common operations stay O(1) or O(log n).
No expensive per-request disk I/O. Persistence (RDB snapshots / AOF append-only file) runs off the hot path.

Speed is a consequence, not a feature

Memory + single-thread + efficient structures + avoiding disk I/O = extremely low latency. But that same design imposes consequences: data size is bounded by RAM, and you must consciously choose eviction, persistence, replication and clustering to get durability and scale.

So when you say "Redis is fast," you're really summarising: it keeps data in memory and executes commands one at a time against tuned structures. Everything else — AOF, replication, eviction policies, cluster sharding — is the machinery that keeps that property usable at scale.

Kubernetes — it doesn't understand your code

You know Kubernetes. But who actually keeps your app alive? You deploy a Deployment with 3 replicas. One pod crashes. What happens?

Kubernetes does not "restart your application" because it understands your code. It has no idea what your binary does. Instead, a controller continuously compares two states.

The control loop: observe current state, compare to desired, reconcile the difference, repeat.

Desired state: 3 pods (what you declared).
Current (observed) state: 2 running + 1 crashed.
Difference? One pod short.
Action: schedule one more pod to close the gap.

The core idea behind Kubernetes

Desired state → Observe → Reconcile → Repeat. This is the reconciliation loop, and it is the mental model for almost everything Kubernetes does — Deployments, ReplicaSets, Services, even custom operators. It never "runs your app"; it perpetually nudges reality toward your declaration.

That's why a Kubernetes restart isn't a restart in the process sense. The crashed pod is just gone from the observed state, the controller sees the gap, and it creates a replacement. When you deploy a new image, you're really updating desired state and letting the loop roll pods forward and old ones out.

Database index — a sorted map that avoids work

You know indexes make queries faster. But what are they actually doing? They aren't a magic "go faster" switch. An index is a separate sorted data structure that lets the database skip work.

Without an index the database scans every row; with an index it navigates a structure to the matching rows.

-- Without an index: scan every row
SELECT * FROM users WHERE email = 'a@b.com';
-- checks Row 1 -> Row 2 -> ... -> Row 10M  (O(n))

-- With a B+ tree index on email:
-- navigate the tree to 'a@b.com' -> row location  (O(log n) + reads)

The same query, two very different amounts of work.

Indexes aren't free

They consume storage, and every insert/update/delete must also update the index structure. A table with many indexes reads fast but writes slow. Indexing is a trade-off, not an unqualified improvement — and an unused index is pure write-time cost.

The deeper insight: an index is about avoiding work. A full scan does O(n) comparisons and row reads; a B+ tree does O(log n) comparisons and reads only the matching leaf pages. The win isn't "speed," it's "not reading ten million rows to answer one question."

Load balancer — traffic management + health management

You know a load balancer distributes traffic. But how, and based on what? A request arrives and the load balancer decides where it goes.

The load balancer distributes requests and skips backends that fail health checks.

Strategy	Decides by	Good for
Round robin	Next server in rotation	Even, similarly-sized servers
Least connections	Server with fewest active requests	Uneven request cost
Weighted	Server capacity weights	Mixed hardware sizes
Health-checked	Is the backend actually healthy?	Avoiding dead backends

It is not just 'send to different servers'

Before forwarding, a load balancer answers "is this server actually healthy?" through periodic health checks. Unhealthy backends are drained from rotation and re-added when they recover. So a load balancer is part traffic management and part health management — and often part TLS termination and part failover too.

CDN — move data physically closer

You know a CDN makes websites faster. But where does the response actually come from? It isn't always your origin server.

Cache hit returns from the edge; cache miss fetches from origin and caches for future users.

Cache hit: the edge already has the asset — return it immediately, no origin trip.
Cache miss: the edge fetches from the origin, stores the response, and future users in that region get it from the edge.

The real idea

Move frequently requested data physically closer to users. Latency is partly speed of light and distance, so the shortest path to the user is a copy of the data near them. A CDN is essentially a globally distributed cache whose value is geographic proximity.

This is why a cache hit is not just "fast" but qualitatively different: the request may never reach your infrastructure at all, so your origin is shielded from load and the user gets a response from a nearby city instead of a distant data centre.

Docker — isolated processes sharing a kernel

You know Docker equals containers. But what is actually happening? A container is not a lightweight virtual machine. There is no guest operating system per container. Docker composes a few long-standing Linux features to make ordinary processes behave like isolated environments.

Containers share one host kernel while namespaces, cgroups and a container filesystem provide isolation.

Namespaces isolate what a process can see — its own process IDs, network, mount tree, hostname.
cgroups limit how much CPU, memory and I/O a process (or group) may consume.
Container filesystem gives the process an isolated, layered view of files via an image.

Why containers are lighter than VMs

Because every container shares the same host kernel, there is no per-container guest OS to boot. Starting a container is essentially starting a process — milliseconds, not the seconds a full VM boot takes — and you pay no memory tax for N operating systems. The isolation is process-level and kernel-enforced, not hardware-level.

API gateway — the central traffic-control layer

You know an API gateway sits in front of your services. But it can become the traffic-control layer for your entire system. Instead of each service re-implementing the same cross-cutting concerns, the gateway handles them centrally.

Authentication, rate limiting, routing, validation, logging and load balancing are handled once at the gateway.

Authentication — verify the caller once before any service sees the request.
Rate limiting — throttle per client, per route, per token.
Routing — map a path to the right service.
Request validation — reject malformed payloads early.
Logging / tracing — a single place to observe all inbound traffic.
Load balancing — distribute across service instances.

Centralisation is the benefit and the risk

Moving these concerns into the gateway removes duplication — but it also concentrates the blast radius. If the gateway fails, everything behind it fails. So the gateway itself must be highly available, and truly service-specific logic still belongs in the service.

WebSockets — a connection that stays open

You know WebSockets mean real-time communication. But why are they different from normal HTTP? The difference is the lifetime of the connection and who is allowed to initiate a message.

HTTP is request then response; a WebSocket is a persistent, bidirectional connection.

	HTTP	WebSocket
Model	Request → Response	Persistent, bidirectional
Who initiates	Client starts each exchange	Either side, any time
Connection	Generally short-lived per request	Stays open after handshake
Overhead	Headers per request	Handshake once, then frames
Best for	Document fetch, APIs	Chat, live dashboards, games, notifications

The mechanism

A WebSocket starts as an HTTP request with an Upgrade header; once the server agrees, the same TCP connection is promoted to a full-duplex frame-based protocol. Either side can push a frame whenever it has data — no polling, no waiting for the client to ask.

The real point

Knowing the name is not understanding the technology. You don't need to memorise:

❌ Kafka definitions
❌ Kubernetes buzzwords
❌ Redis feature lists
❌ Docker commands

You need to understand the questions underneath all of them:

What happens underneath? What is the actual mechanism when you press the button?
Why was it designed this way? What constraint forced this shape?
What problem does it solve? And what does it deliberately not solve?
What happens when it fails? Which assumption breaks, and what is the blast radius?
How does it scale? Where does the parallelism live, and where is the ceiling?

That's where real engineering understanding starts

Each technology above is a specific answer to these questions. Kafka answers them with an append-only log and per-consumer offsets. Redis answers them with in-memory data and a single thread. Kubernetes answers them with a reconciliation loop. The names differ; the discipline of asking "what happens underneath" is the same.

Interview framing

If an interviewer asks "explain Kafka," a surface answer is "a messaging system." A real answer is: "Kafka is a durable, partitioned, append-only log. Producers append keyed records to a partition; the partition is the unit of ordering and parallelism. Each record gets an offset, and because reading never deletes, multiple consumer groups replay the same log independently. Durability comes from replication with an ISR and acks=all. The design trades global ordering for horizontal scale — and that trade-off is what you reason about when sizing partitions and choosing keys."

Notice the structure: what it is → how the mechanism works → what trade-off that mechanism implies → what you therefore decide. Apply that same structure to Redis, Kubernetes, indexes, load balancers, CDNs, Docker, API gateways and WebSockets, and you move from recall to understanding.