Systems fundamentals

What it is

This label covers questions that hand you a mechanism most engineers can name — consistent hashing, an LSM tree, TCP versus UDP, what a cache line is, what happens when a browser loads a page — and ask you to explain it well enough to make a decision or a quantitative estimate, not just define it. There's rarely code to write; the deliverable is a clear, mechanism-level explanation: what happens at each layer, what it costs, and where the tradeoff actually bites, defended with rough numbers rather than hand-waving.

When it applies

• The question is "explain X" or "choose between X and Y for this scenario, and justify it," where X is a well-established concept (a protocol, a data structure, a scheduling unit, a hashing scheme) rather than a system you're being asked to design from scratch.
• A correct answer requires connecting a named mechanism to its consequences with actual numbers: how much data moves, how many round trips happen, how much slower a specific hardware interaction is.
• Two options are both individually well known and the interesting part is the criterion for choosing between them in a specific scenario, not implementing either one.
• A prompt that wants you to compose several such mechanisms into a new system with its own components and scale numbers is hld instead — this tag is for one mechanism explained in depth, not several assembled into an architecture.

Tells in the problem

• "Explain what is happening at the hardware/protocol/algorithm level" rather than "design a system that..."
• A request to be quantitative — "estimate how much slower," "give a round-trip budget," "quantify write amplification" — rather than a qualitative comparison.
• A concrete before/after or two-column scenario ("TCP guarantees... TCP costs...", a naive version versus a fixed version) that the answer is expected to walk through symmetrically.
• A named concept in the title or opening line that most engineers have heard of but may only be able to define loosely (a cache line, a virtual node, a coroutine).
• A "then explain what changes if..." follow-up that tests whether the explanation generalizes past the one example given.

The classic mistake

Answering with the textbook definition of the mechanism instead of tracing its actual consequence in the given scenario is the error that comes up most — reciting "consistent hashing spreads keys around a ring" without ever computing what fraction of keys move when a server is added, or naming "TCP guarantees ordered delivery" without connecting that guarantee to the specific stall it causes on the lossy link in the question. This happens because the vocabulary is familiar enough to produce a fluent-sounding answer without doing the underlying arithmetic. Catch it by asking yourself, before you speak, "what number does this fact produce for the scenario I was actually given" — if you can't produce one, the explanation isn't finished yet.

Questions to start with

• Process vs Thread vs Coroutine — three concrete workloads, forcing you to match a concurrency primitive's real cost to what each workload actually needs.
• TCP vs UDP: Choose for a Scenario — six scenarios where the right transport depends on one recurring question, a good way to build the "what number does this produce" habit.
• Consistent Hashing Explained — a single mechanism with a clean before/after quantity (fraction of keys remapped) to compute and defend.
• LSM Tree vs B-Tree — a genuine two-workload tradeoff, where the answer must be a per-table decision backed by amplification math.
• What Happens When You Load a URL — the broadest one, chaining several mechanisms together into one round-trip budget.