LEARNING PATH · Systems & Backend

Level Up as a Backend Engineer

For backend engineers going deeper on distributed systems.

Advanced ~3h 15m8 lessons10 steps

The distributed-systems fundamentals, then the systems that put them to work — a key-value store, a cache, a message queue, an ID generator — with tools to build the intuition.

Reason about replication, partitioning and coordination
Choose consistency and quorum settings deliberately
Recognize the same primitives across very different systems

0 / 8 done · 0%

How this path works

This path is for working backend engineers who ship endpoints and schemas comfortably and now want to reason about what happens beyond a single database: the engineer who gets pulled in when a cache stampedes, or who has to choose a consistency level and defend it in a design review. It is marked advanced because it assumes production experience, not because the math is hard.

At this level the job, and the senior interview, tests whether you can predict behavior under failure and contention. Can you say what a replica returns after a partition heals, why a retried message was processed twice, or how many nodes must acknowledge a write before it counts as durable? Those questions reduce to a handful of primitives: partitioning, replication, locking, consensus and quorums.

So the path teaches the primitives first, in four handbooks, then shows them recombined in four real systems: a key-value store, a distributed cache, a message queue and a Snowflake-style ID generator. Each design uses the same ideas in different proportions, and noticing that is the skill. Two calculators close the path, so you can put numbers on quorum settings and on what a chain of dependencies does to availability.

What each step gives you

The System Design Fundamentals Handbook
A compact pass over the four ideas the rest of the path builds on, plus a section on statelessness and horizontal scaling that explains the sticky-session trap and where state is supposed to live. Treat it as a calibration check: if you can already explain read-your-writes consistency and why a second app instance breaks in-memory sessions, skim it and move on.
Partitioning, Sharding & Replication
How one dataset becomes many: range, hash and directory partitioning, consistent hashing with virtual nodes, picking a shard key that avoids hot partitions, and single-leader, multi-leader and leaderless replication. It prepares you for real decisions, such as choosing the partition key for a fast-growing table and estimating how much data moves when you add a node, which the page lets you count directly.
Concurrency, Locks & Isolation Levels
Correctness under contention: the races behind lost updates and double-spends, pessimistic versus optimistic locking, what each SQL isolation level actually prevents, how MVCC stops readers and writers blocking each other, and fencing tokens for distributed locks. Use it to settle questions you meet in code review, such as whether a read-modify-write needs a row lock or a version check, and how ordering lock acquisition prevents a deadlock.
Consensus, Transactions & Coordination
How machines that can crash still agree: why agreement is hard, majority quorums, Raft's elected leader and replicated log, Paxos, coordination services such as ZooKeeper and etcd, two-phase commit versus sagas, and idempotency. The practical payoff is knowing when to lean on an existing coordination service instead of building agreement yourself, and how to make a multi-service workflow safe to retry.
Design a Key-Value Store
The first system that combines every primitive: consistent hashing to place keys, replication along a preference list, tunable quorum reads and writes, conflict resolution when replicas diverge, gossip for membership, and hinted handoff with read repair to heal after failures. Read it as a case study in trade-offs, then test yourself on the page's harder questions, such as what a node does when it rejoins the cluster.
Design a Distributed Cache
A Redis- or Memcached-style cache built up from cache-aside: sharding with consistent hashing instead of modulo, eviction with LRU, LFU and TTLs, replication and failover, invalidation, and coalescing misses so one expired key does not stampede the database. It prepares you for production questions like how to pick a TTL, what to do about a hot key, and what happens after a mass flush.
Design a Message Queue
A Kafka-style log designed from first principles: an append-only log, partitions for parallelism with ordering only within a partition, consumer groups that track offsets, leader-and-ISR replication, leader election for metadata, retention and compaction, and delivery guarantees. It is the background you need when choosing a partition key, sizing a topic, or explaining why exactly-once rarely survives the trip to an external sink.
Design an ID Generator
Why unique IDs get hard at scale and how a Snowflake-style layout solves it: a millisecond timestamp in the high bits for rough ordering, a machine ID field, a sequence counter, safe assignment of node bits, and handling a clock that moves backward. You come away able to compare it with UUIDs and ticket servers, and to explain what an ID leaks and why it is only roughly sorted.
Quorum (N/R/W) Explorer
Set N, R and W and see immediately whether reads are guaranteed to overlap the latest write, how many replica failures reads and writes each survive, and where the setting sits between latency and consistency. Use it to rehearse the settings you would actually choose, such as majority quorums for balanced workloads or W equal to N for read-heavy data, and to explain what each one costs.
Availability (Nines) Calculator
Compose dependencies in series and in parallel and read off combined availability, the number of nines and the downtime per year and per month. It makes one backend lesson stick: every synchronous dependency multiplies into your own uptime, so three services at 99.9 percent in a row land near 99.7, and redundancy on the critical path is how you earn nines back.

A study plan

Week 1
Read System Design Fundamentals and Partitioning, Sharding and Replication. Pick a table from a system you work on and write down its partition key, its likely hot keys and what would happen if you doubled the node count. Then use the page's key-counting exercise to check your intuition.
Week 2
Read Concurrency, Locks and Isolation Levels and Consensus, Transactions and Coordination. Find one read-modify-write in your own codebase and decide whether it is safe at its current isolation level. Sketch how you would make one multi-step workflow idempotent and safe to retry.
Week 3
Work through the key-value store and the distributed cache. For each, close the page and redraw the final architecture from memory, then note which handbook idea each component uses. Answer the interviewer questions at the end of each design before you read the explanations.
Week 4
Finish the message queue and the ID generator, then spend an hour with the Quorum Explorer and the Availability Calculator. Model a real dependency chain from your own system, compute its expected downtime, and write a one-page proposal for the redundancy you would add first.

Questions about this path

What distributed systems concepts should a backend engineer know?

The core set is small: partitioning and replication, consistency models and the CAP trade-off, concurrency control and isolation levels, consensus and leader election, quorum reads and writes, idempotency and delivery guarantees, and caching with invalidation. You do not need to implement Raft, but you should be able to predict what your database, cache and queue do when a node fails or two writes collide. This path covers each concept in a handbook and then shows it at work inside a real system design.

How long does it take to learn distributed systems as a backend engineer?

With production backend experience, a month of steady study is enough to work through the material in this path and start applying it in design reviews. Deep fluency takes longer and mostly comes from operating systems and investigating their failures. A useful approach is to pair each concept with something you run: after the partitioning handbook, look at how your own database shards; after the message queue design, look at your consumer lag. Connecting the ideas to systems you already operate makes them stick much faster.

How do I choose N, R and W for a replicated database?

Start from the failure you must survive and the reads you must get right. N is the number of copies, commonly three. If reads must always see the latest write, choose R and W so that R plus W is greater than N, such as majority quorums of two out of three. If writes must keep succeeding while replicas are down, lower W and accept that some reads may be stale. Read-heavy data often uses a high W and a low R. The Quorum Explorer lets you try each setting and see what it survives.

When should a backend use a distributed cache?

Use one when reads clearly outnumber writes, the same keys are requested repeatedly, and serving slightly stale data for a bounded time is acceptable. Cache-aside is the usual starting pattern: read from the cache, fall back to the database on a miss, then populate the cache. The hard parts are invalidation when the source changes, hot keys that overload one shard, and stampedes when a popular key expires. If you cannot tolerate any staleness, or the hit rate would be low, a cache adds risk without much benefit.

The backend engineer's core

Backend work is a small set of durable ideas applied over and over: how to store data correctly under concurrency, how to scale past one machine, how to stay fast with caching, and how to stay up when parts fail. This path threads those fundamentals through the system designs that make them concrete — a key-value store, a distributed cache, a message queue, an ID generator.

It favours understanding over trivia: once you can reason about consistency, partitioning, caching and failure, most "how would you build X" questions — in interviews and in the job — become variations on patterns you already know.

← All learning paths

The System Design Fundamentals Handbook

Partitioning, Sharding & Replication

Concurrency, Locks & Isolation Levels

Consensus, Transactions & Coordination

Design a Key-Value Store

Design a Distributed Cache

Design a Message Queue

Design an ID Generator

Quorum (N/R/W) Explorer

Availability (Nines) Calculator