Zero to System Design

Before tuning anything, you need a shared definition of what growing pains look like.

Two numbers describe every system’s performance, and beginners constantly mix them up.

When machines disagree, you must choose: answer fast or answer correctly.

Nothing loads until a name becomes an address, DNS is step zero of every request.

Some data must arrive perfectly; some must arrive now, the protocol picks the priority.

Encryption and chatty connections quietly dominate real-world latency budgets.

A server that sits in front of your servers handles the chores every app repeats.

A traffic cop in front of your servers decides who handles each request.

Adding machines only works if any machine can serve any user.

Dumb-fast packet routing and smart content routing solve different problems.

Most of the world’s critical data still lives in tables with guarantees.

Reads are fast or slow for physical reasons, indexes and logs decide.

One database is a single point of failure; copies turn failure into a non-event.

When one machine can’t hold the data, you slice it across many.

Concurrent writes invite weird bugs, isolation names the weirdness you'll tolerate.

The default answer is usually relational, learn when it isn't.

Duplicating data feels wrong until joins get too slow to serve.

When all you need is lookup by key, the simplest store is the fastest.

Memory answers in microseconds what disks answer in milliseconds.

The pattern you pick decides what breaks when the cache empties at once.

Physics says distant users wait longer, so put copies near them.

Client, CDN, app, and database caches each solve a different latency problem.

One popular key can overload a shard and take the cache down with it.

Background work needs a waiting room, the shape of the room matters.

“Did it arrive once?” is three different engineering problems wearing a trench coat.

The industry’s default log, partitions decide your parallelism ceiling.

One poisonous message should never wedge your entire pipeline.

Background jobs need retries, scheduling, and a place to live.

A producer faster than its consumer doesn't lose data, it loses the system.

Chat and live feeds need the server to push, not wait for a poll.

Store what happened, not only the latest state, and history becomes data.

Some answers are needed continuously, not in tonight's batch.

Auth, encryption, and hashing are assumed knowledge the moment you ship.

Modern login hands out tokens, and their lifetime is a security decision.

You cannot fix what you cannot see, and production is where the truth lives.

The style of your API decides how clients evolve with it.

Networks drop replies, so clients retry, and retries duplicate work.

During a network split you cannot have both fresh and available, pick consciously.

Adding a server shouldn’t reshuffle everyone’s data.

A cluster needs exactly one leader, elections are how it agrees on one.

Sometimes “probably not here” answered in nanoseconds beats certainty.

"Latest value" has grades, from strong to eventual, each with a cost.

Uptime is engineered with redundancy, not hoped for.

Distributed machines disagree about the time, and ordering depends on it.

A cluster can share state without a central coordinator, by rumour.

Databases can't hand out IDs fast enough, so generation moves to the edges.

Dependencies will fail, the only question is whether they take you down too.

One greedy client should never starve everyone else.

Splitting systems buys independence, and a brand-new category of failures.

Knowing is half the interview, explaining trade-offs under pressure is the rest.

Confidence lies; scores don’t, find the gaps before an interviewer does.