System Design Classics and Blocks

What a building block is

A building block does one job for many systems. A product does many jobs for its users.

One block might hold data in memory for fast reads. Another might store files, or carry messages between systems.

Blocks stay small in purpose. Small purpose keeps a block easy to reuse.

A product stands on several blocks at once. A social app reads fast data, stores photos, and sends messages through different blocks.

The ask

An interview starts with a short request. The request names a system, and little else.

The first job is narrowing the request. Ask what the system must do, and what it can skip.

Ask who calls the system. Ask how fast answers must be.

Good questions turn a vague request into clear requirements. Clear requirements drive every later choice.

Estimate the scale

Estimation turns daily counts into rates per second. Rates show how much machinery a design needs.

1,000,000 requests a day / 86,400 seconds a day = about 12 requests per second.

Storage gets the same treatment. Count the items, multiply by the size of one item, and the total appears.

Round numbers are fine at this stage. The aim is the right size of system, not exact counts.

API and data

The API is the set of operations callers can use. Each operation needs a name, inputs, and a result.

A block API stays small and stable. Many systems depend on it, so changes spread widely.

Data choices come next. Name what gets stored, where it lives, and how long it stays.

Reads and writes rarely balance. The heavier side shapes the design.

High-level design

The high-level design names the main parts and their connections. Callers, the block itself, and its storage form the usual shape.

Arrows show the flow of a request. A request enters, the block answers, and storage helps only when needed.

Keep the first shape simple. Depth comes from pressure points, not from extra parts.

Deep dive

The deep dive picks the hardest pressure point. One part gets close attention while the rest stays simple.

Pressure points differ by block. One block struggles with hot data, another with keeping copies in agreement.

Failure belongs in the deep dive. State what breaks, what callers see, and how the system recovers.

Numbers return here. A fix that sounds good must still fit the estimated scale.

Evaluation and trade-offs

Evaluation compares the design against the requirements. Speed, cost, and reliability rarely all win.

Every choice gives something up. Naming the loss is part of the design.

A strong answer ends with the weakest point stated plainly. A named weakness invites the next improvement.

A block beside a product