Backend Engineering Roadmap

Start at Request in, response out. Nine stages in one order; every stage names what it needs first and what you should be able to build before moving on, and each assumes the failure modes of the ones before it. Progress is stored locally in your browser.

Where to start

Backend engineering

9 stages · 0/200 lessons

What happens from the moment a request reaches the service until data is returned, persisted, queued, cached, retried, observed and served at scale.

Start here: Request in, response out — first lesson What a Backend Actually Is
  1. Request in, response out
  2. Structure, data access and who is calling
  3. Transactions, queries, caches and other people's APIs
  4. Work that outlives the request
  5. Timeouts, retries, idempotency and limits
  6. Observability, testing, security and performance work
  7. Scaling out and shipping without dropping requests
  8. Distributed patterns, failure handling and multi-tenancy
  9. Production backend engineering
0 / 200 lessons masteredNot started 200Learning 0Practicing 0Mastered 0
  1. 1

    Request in, response out

    Start here
    0/17

    The request lifecycle with the framework removed: what a backend is responsible for because the client cannot be trusted with it, how a socket becomes a request object, how a method and a path pick a handler, the middleware pipeline every request passes through, and where malformed input is rejected. Everything later assumes you can see this path end to end.

    Before moving on: Build an HTTP service that rejects malformed input at the edge, runs a handler and returns the right status code, and explain what happened between the socket and the response body without naming a framework.

  2. 2

    Structure, data access and who is calling

    0/19

    Once a handler works, the question is where the rest of the code goes. Service and repository layers keep handlers thin and business rules testable, business validation is separated from the transport validation of the first stage, and the data access layer — ORM, query builder or raw SQL — is chosen per query, with a look at what an ORM actually does under the method call. Then authentication establishes who is calling and authorization decides what they may touch, down to the object-level check whose absence is the most common serious backend vulnerability. This is where a personal project becomes something other people can safely log into.

    Before moving on: Build a service with thin handlers, business rules in a testable layer and an object-level authorization check on every resource, and explain why authentication and authorization are different questions.

    Needs first:Request in, response out
  3. 3

    Transactions, queries, caches and other people's APIs

    0/20

    The data path under load. Transaction boundaries and why a network call inside one is a resource problem; ORM, query builder and raw SQL as an engineering decision; the N+1 pattern and the connection pool that is the real concurrency limit; cache-aside with invalidation and TTLs, and the cases where a cache buys nothing; a timeout on every call that leaves the process; and DTOs so the database row is not what the client sees. It builds on the repository layer from the previous stage.

    Before moving on: Decide what belongs in one atomic unit, write list endpoints whose query count does not grow with the result set, add a cache you can invalidate, and put a timeout on every external call.

    Needs first:Structure, data access and who is calling
  4. 4

    Work that outlives the request

    0/19

    Work that does not belong in the request path. Deciding what to defer, the queue lifecycle from enqueue to dead-letter, commands versus events and the consumers that act on them, inbound webhooks verified on the raw payload, and uploads that go straight to object storage through presigned URLs. It comes after the data stage because a job is a transaction that finishes later, and the recurring question is what the user sees while the work is still running.

    Before moving on: Move a slow step off the request path onto a queue with a dead-letter policy, verify an inbound webhook signature on the raw body, and accept a file upload that never passes through your process.

    Needs first:Transactions, queries, caches and other people's APIs
  5. 5

    Timeouts, retries, idempotency and limits

    0/20

    The stage that makes the previous two safe. Retries with backoff and jitter, circuit breakers and bulkheads for a flaky dependency, and the rate limits you enforce; idempotency keys so a client that presses the button twice is charged once; at-least-once delivery and duplicate detection for jobs and webhooks; and two requests on one row, resolved with optimistic versioning, pessimistic locks or atomic operations. Every retryable path becomes a safe-to-retry path, and every unbounded thing gets a bound.

    Before moving on: Make every retryable path safe to retry with an idempotency key, bound a flaky dependency with a timeout, backoff and a circuit breaker, and choose optimistic or pessimistic locking for a two-requests-one-row race.

    Needs first:Transactions, queries, caches and other people's APIsWork that outlives the request
  6. 6

    Observability, testing, security and performance work

    0/22

    Operating the service you can now build. An error taxonomy and error boundaries that stop internals leaking; correlation ids, structured logs, metrics, traces and health checks so you can answer questions you did not anticipate when you deployed; configuration and secrets kept out of the code; a test strategy chosen by what each layer can prove, including integration tests against a real database and performance tests that measure more than one requests-per-second number; and the security checklist every service owes, from SQL injection to SSRF.

    Before moving on: Follow one slow request through logs, metrics and traces, prove a change is safe with an integration test against a real database, and pass a security review of the service itself rather than of the network in front of it.

    Needs first:Timeouts, retries, idempotency and limits
  7. 7

    Scaling out and shipping without dropping requests

    0/20

    More than one copy of the service. Statelessness is what makes horizontal scaling and load balancing possible; then read replicas, pagination and autoscaling signals, and shipping without dropping requests: containers, graceful shutdown, rolling deploys and expand-contract migrations that two versions read at once. The runtime-model lessons sit here because the runtime decides what one instance can handle before you add a second.

    Before moving on: Run the service behind a load balancer with no in-memory state, deploy a new version while the old one is still serving, and migrate a schema that both versions read at the same time.

    Needs first:Observability, testing, security and performance work
  8. 8

    Distributed patterns, failure handling and multi-tenancy

    0/21

    What changes when a function call becomes a network call. Monolith, modular monolith and microservices compared honestly; failure propagation and cascading failure; the dual-write problem and the transactional outbox; eventual consistency; multi-tenancy and tenant isolation; and the concurrency of a shared system: backpressure, cache stampedes, request coalescing and deadlocks. It needs the retry and idempotency stage as much as the scaling one, because every pattern here is a retry across a network.

    Before moving on: Explain what happens when half of a write succeeds and fix it with a transactional outbox, stop one slow dependency from taking down services that do not depend on it, and isolate tenants so one deployment never leaks data between customers.

    Needs first:Scaling out and shipping without dropping requestsTimeouts, retries, idempotency and limits
  9. 9

    Production backend engineering

    0/42

    The rest of the domain, read with the judgement the earlier stages built: production debugging from symptom to cause, the runtime internals of Node, Python and worker processes, canary and blue-green deploys with feature flags, the low-level HTTP mechanics of accepting connections and parsing requests, the remaining structure and auth lessons, and agent-enabled backends, where a model choosing a tool is a client choosing an endpoint.

    Before moving on: Take an API that was 100 ms yesterday and is 3 s today from symptom to cause, ship the mitigation behind a canary or a feature flag, and say what to change and what to leave alone.

    Needs first:Distributed patterns, failure handling and multi-tenancyObservability, testing, security and performance work