Backend Engineering Roadmap
Nine levels, each defined by what you can build once you have it rather than by what you have read. The order matters: every level assumes the failure modes of the one before it.
Request in, response out
You can build an HTTP service that accepts a request, rejects malformed input at the edge, runs a handler and returns a correct status code — and you can explain what happened between the socket and the response body without pointing at a framework.
Structure, data access and who is calling
You can build a service whose handlers are thin, whose business rules live somewhere testable, and which knows both who the caller is and what that caller is allowed to touch. This is the level at which a personal project becomes something other people can safely log into.
Transactions, queries, caches and other people's APIs
You can decide what belongs in one atomic unit, write queries that do not multiply with the result set, add a cache that does not lie, and call a third party without your own service hanging when theirs does.
Work that outlives the request
You can move work off the request path deliberately — jobs, queues, events, inbound webhooks and uploads that never touch your process — and answer "what does the user see while that is still running?".
Timeouts, retries, idempotency and limits
You can build a service that survives a flaky dependency and a client that presses the button twice — because every retryable path is also a safe-to-retry path, and every unbounded thing has a bound.
Observability, testing, security and performance work
You can answer questions about production that you did not anticipate when you deployed, prove a change is safe before shipping it, and pass a security review of the service rather than of the network in front of it.
Scaling out and shipping without dropping requests
You can run more than one copy of your service behind a load balancer, deploy a new version while the old one is still serving, and migrate a schema that two versions are reading at the same time.
Distributed patterns, failure handling and multi-tenancy
You can reason about a system where a function call has become a network call: what happens when half of a write succeeds, how one slow dependency takes down three services that do not depend on it, and how one deployment serves customers who must never see each other.
Production backend engineering
You can be the person who is called when the API was 100 ms yesterday and is 3 s today: reason from symptom to cause, ship the mitigation safely, and hold the operational judgement about what to change and what to leave alone.