Backend and Its Neighbours
Which question belongs to which domain, so you look for answers in the right place.
The requirement, the obvious build, and why it breaks
Every lesson starts where the work starts: someone asked for something, and the first implementation that comes to mind has a problem.
When something is hard, which domain's question am I actually asking?
An engineer hits a problem and needs to know whether it is an API design question, a database question, an architecture question or a backend one.
It is all backend. Anything server-side is one big subject.
Treating a data-modelling problem as an application problem produces application code that compensates for a schema that should change.
- Treating a data-modelling problem as an application problem produces application code that compensates for a schema that should change.
- Treating a contract problem as an implementation problem produces endpoints whose shape follows internal structure (Schema Leakage).
- Treating a distributed-systems problem as a coding problem produces retries that make an outage worse (Retry Storms).
What is actually happening
- Each domain owns a distinct question. Backend Engineering owns: how do we implement and operate the service behind the contract?
- The neighbours own: what contract (API Design), what storage (Database), what structure (Architecture), where it runs (Cloud), why it is slow (Performance), how it is attacked (Security), how interleavings behave (Concurrency).
- Problems that feel intractable in one domain are often routine in another. Recognising the owner is most of the work.
Whose question is this?
Read the middle column as the symptom you actually experience. The right-hand column is where the answer lives.
| You are asking | Owner | Where the depth is |
|---|---|---|
| Should this be one endpoint or three? | API Design | Contracts, versioning, consumer needs |
| Why is this query slow? | Database Engineering | Indexes, plans, storage |
| How do I call the database from application code without N+1? | Backend | This domain (The N+1 Query Problem) |
| Should this be one service or several? | Software Architecture | Boundaries, coupling |
| Where does this run and what does it cost? | Cloud & Infrastructure | Compute models, managed services |
| Which of the seven hops is the slow one? | Observability & Performance | Profiling, tracing, queueing |
| How would an attacker exploit this? | Security Engineering | Threat models, technique |
| What must I enforce server-side so they cannot? | Backend | This domain (The Backend Security Checklist) |
| What happens when these two run at once? | Concurrency & Parallelism | Interleavings, memory models |
| How do I stop two requests double-charging? | Backend | This domain (Optimistic Concurrency) |
The pattern in the pairs
Notice the shape of the rows that stay here. Neighbouring domains own the *phenomenon*; this domain owns the *enforcement point in a running service*. Concurrency explains why two interleaved writes lose an update; Backend Engineering is where you add the version column and decide what the caller sees on conflict.
That is what "integration domain" means in practice. It is not a summary of the others — it is the layer where their conclusions become code that runs, fails, is observed and is deployed.
- Database owns the index; we own the query the ORM emitted and the pool it waited for.
- Security owns the exploit; we own the check that refuses it.
- Performance owns the queueing model; we own the pool size and the timeout.
- Cloud owns the platform; we own graceful shutdown and health checks (Graceful Shutdown).
How to build it
Most important first.
- When stuck, ask which question you are really asking, then read that domain's material rather than adding another layer here.
- When designing, walk the neighbours deliberately: contract, storage, structure, deployment, observability, security.
- Deep-link rather than re-explain. A backend lesson that teaches B-tree internals is in the wrong place.
What can go wrong
- Solving a schema problem with caching.
- Solving a contract problem with a version flag inside the handler.
- Solving a capacity problem with retries.
- Security Engineering owns attacker technique; this domain owns the server-side enforcement point. Confusing them produces services that know about OWASP and still have no authorization check.
- "Backend includes everything server-side, so all of it is my call." Storage and contract decisions have their own owners and constraints.
- "These are just tags." They change where you look for prior art — the difference between an afternoon and a week.
Operating it
- When an incident review names a cause, note which domain owns it. A pattern of causes in one neighbour tells you where the team's knowledge gap is.
- At small scale the boundaries genuinely blur, and one person holds all of them. At larger scale they become team boundaries, and mismatched ownership becomes an organisational problem.
- Strict boundaries can become handoffs and delay. The point is knowing where an answer lives, not refusing to look outside your area.
Where this applies
Backend advice is context-sensitive. These labels say what each claim is specific to, and where a different stack or scale would differ.
- GENERALA conceptual map; independent of stack.
- SCALE-SPECIFICIn a small team one person owns every column and the boundaries are advisory. Past roughly a few teams they harden into ownership, and the handoffs become the expensive part.
Where the depth lives
This domain teaches the application-side mechanism and hands the rest off.
- — Distributed Systems — consensus, replication and partition behaviour, once one service becomes several.
- — System Design — sizing and shaping an entire system rather than one service.