What to learn, in what order, to what depth

Sixteen topics that appear in essentially every system you will ever build, which is what makes them tier 1: requirements, capacity estimation, APIs, data modeling, SQL, caching, queues, concurrency, transactions, consistency, availability, reliability, security, observability, scaling and trade-offs. "Master" needs a testable meaning or the tier is just an ordering. Here it means two things. First, you can use it without looking it up — not that you remember every option, but that you can produce a working design and the right vocabulary in a conversation, at a whiteboard, with no reference material. Second, and more demanding, you know the failure mode and not only the happy path. Anyone can describe a cache; mastering caching means knowing what a miss storm on a hot key does, and what a stale entry costs in the specific workflow you are caching. That second half is what separates tier 1 from having read about something. The list also has an internal order — requirements and capacity estimation come first because they produce the numbers every later decision is checked against, and trade-offs comes last because it is the skill of choosing between things you now understand well enough to compare. Getting all sixteen to that standard is a multi-year effort, and it is the difference between an engineer who can build a feature and one who can be handed a system.

Tier 1, in the order they get used

  BEFORE YOU BUILD
    requirements -> capacity estimation
    -> APIs -> data modeling

  THE DATA LAYER
    SQL · caching · queues · transactions

  CORRECTNESS UNDER LOAD
    concurrency · consistency
    availability · reliability

  RUNNING IT
    security · observability · scaling
    trade-offs

Master = usable with no reference material,
AND correct about the failure mode.

Thirteen topics you meet often but not always: Kafka and RabbitMQ, sharding, read replicas, distributed transactions, sagas, the transactional outbox, rate limiting, search, object storage, multi-tenancy, cloud services, Docker and Kubernetes, and disaster recovery. The standard here is lower than tier 1 and still specific. You must recognise when the topic applies, be able to design with it at a whiteboard, and know its main failure mode — but you may look up the configuration, the exact API and the operational details. So: you should be able to say that a workflow spanning two services needs a saga with compensating actions, sketch the steps and name what happens if a compensation fails, without remembering any particular framework's decorator syntax. The distinction that matters is recognition versus recall. Failing to recognise that you need an outbox produces a system that silently loses events; failing to recall the exact column types costs five minutes with the documentation. Tier 2 is also where most over-engineering originates, because each of these is genuinely powerful and adopting one without the requirement that justifies it imports its whole cost — Kafka brings partitions, consumer groups, rebalancing and lag monitoring whether or not you needed replay.

Tier 2 — the standard, stated as a test

  Given a requirement, can you:
    1. name the tier-2 topic it needs?
    2. sketch the design on a whiteboard?
    3. say its main failure mode?
  Then you have strong working knowledge.

  Not required: config, API surface,
  operational runbooks. Look those up.

  The expensive failure is (1).
  Missing "this needs an outbox" loses
  events silently. Forgetting the column
  types costs five minutes.

Six topics where understanding the idea is the goal and implementing it usually is not: consensus algorithms, multi-region active-active designs, advanced stream processing, custom storage engines, advanced scheduling, and specialized distributed databases. Conceptual is the right depth rather than a concession, because for five of the six the correct move in a real system is to use something that already implements it. You will not write Raft; you will choose etcd or a managed service and need to know what "a quorum of three" buys and what it costs in latency. You will not build a storage engine; you will need to know why a log-structured merge tree is fast at writes and pays for it at read time, so that you can predict how a database will behave under your workload. What you need is the vocabulary to choose well and to reason about a guarantee someone else implemented. The exception is multi-region active-active, which is conceptual for a different reason: it is not that you would use a library, it is that almost no system needs it, and the sections on multi-region systems and disaster recovery cover the decision. Being deep here while tier 1 is shallow is a recognisable pattern and a costly one, because tier-1 topics decide ten thousand times as many designs.

Tier 3 — the test is different

  Tier 1:  can you use it, with no reference?
  Tier 2:  can you recognise it and design
           with it?
  Tier 3:  can you choose a system that has
           it, and reason about the guarantee
           it gives you?

  You will not write Raft. You will pick
  etcd and need to know that a quorum of 3
  survives 1 failure, that 4 nodes survive
  the same 1, and that every write costs a
  round trip to a majority.