Ranking backend concepts from intern to senior, part 1
Six backend concepts placed on a tier list from intern to senior, and the reasoning behind each placement: how much of the system you must hold in your head, not how hard the code is.
Tier lists are unfair by nature, so let me say what the axis actually is. I am not ranking these concepts by how hard they are to learn. I am ranking them by how much of the system you have to hold in your head before you can make a good call about them. A concept is intern-level when the answer lives inside one query. It is senior-level when the answer depends on your team, your traffic and the next two years of the product.
Caching is junior
You will meet caching early, because the first slow endpoint always tempts you into it. What to cache, where to put it and when to invalidate it is a real skill, but it is learnable inside one feature, and the blast radius of getting it wrong is usually one screen showing stale data.
CQRS is senior
Splitting reads from writes is not the hard part. Any competent developer can build a read model. The hard part is deciding whether this application needs that separation at all, and whether the team can keep two models honest for years after you have moved on. The code is cheap; the commitment is not.
Load balancing is mid-level
This is the first concept on the list that forces you to stop thinking about one process. Two instances behind a balancer immediately break in-memory sessions, in-memory caches and in-memory counters. You do not need to operate the balancer yourself, but you need to know your code runs in several copies at once and that no single copy sees the whole picture.
Auth and authz are intern
Not because they are easy to get right, but because knowing they are two different questions is day-one vocabulary. Who are you, and what are you allowed to touch. Every framework, every permission bug and every security review starts from that split, so an intern who confuses the two will misread most of the codebase.
Sharding is senior
The shard key decides how your data is allowed to grow. It is the kind of decision that costs nothing on a whiteboard and is brutally expensive to undo once a few hundred million rows and every query in the product depend on it.
Rate limiting is mid-level
Picking the number is trivial. Making the limit mean the same thing on every instance is not, and that is the mid-level part: the counter has to leave the process, which drags in a shared store, clock skew and a decision about what happens when that store is down.
import { redis } from "@/lib/redis"export async function allow(key: string) {const window = Math.floor(Date.now() / 60_000)const slot = `rl:${key}:${window}`const used = await redis.incr(slot)if (used === 1) await redis.expire(slot, 60)return used <= 100}
Which one would you move?
The placement I expect the most argument about is CQRS, because it is reachable by any competent mid-level developer. I keep it at senior anyway: the code is not what makes it expensive, the commitment to two models is.