Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Backend Engineer

A backend engineer builds the parts of the system the customer cannot see, which is a perfectly safe arrangement until the parts the customer cannot see stop working and the parts the customer can see become a very polite apology. You translate "the app needs to save things" into services, databases, queues, contracts, retries, and the quiet assumption that the network is reliable, a position the network holds only between outages and never during them. You learn that an API is a promise the frontend believes today and the future frontend will litigate, that a database will preserve a typo for twenty years with the diligence of an archivist, and that a retry without idempotency is merely a request for two of whatever you only wanted one of. The work travels from one function that returns the right answer to a fleet of services that return an answer that is eventually, approximately, and defensibly correct while three other services hold different opinions. This guide moves from writing a request handler to setting service architecture across teams, with practical stops at transactions, contracts, partial failure, observability, security, and the recurring discovery that the slow query was always the slow query; it was merely waiting for traffic to make it official. The grand objective is correct behavior under load at a defensible cost; the daily evidence is usually a deploy that does not require a rollback, a queue whose depth returns to zero, and a transaction whose commit survived a colleague's enthusiasm for "just one more column."

Things to recognise

• A handler that returns the right answer for one input is not correct; it is correct for that input, and the next input has been waiting in the lobby with opinions of its own.
• A missing uniqueness constraint does not mean the database enforces uniqueness gently; it means the database will let the second customer register with the poise of a system following orders.
• Confirm the environment, the schema, and the test database before running a query, because a correct query against the wrong database is an act of discovery rather than a feature.

Take the useful exit

Level 1 · Novice

Read the schema before trusting the function to remember what a customer is

You inspect request handlers, schemas, queries, logs, and tests without shipping to production, learning how a polite endpoint can persist a customer into the wrong table before the page finishes rendering.

You begin with read-only artifacts: a service's route handlers, a database schema, sample queries, test files, and logs from a recent request. A request handler is a function that receives input, does work, and returns a response; a schema describes the tables, columns, types, and constraints that decide what the database will accept and what it will reject with the conviction of a bouncer who has read the list. You review these with developers, a database-aware reviewer, and an experienced engineer so everyone can trace how input becomes output before anyone writes a row whose correction will outlast their employment.

Suppose a team wants to add a "save profile" feature. In a sandbox with no production access, you read the handler, follow the input into a parameterised query, inspect the schema's nullability and unique constraints, and note that an email column has no uniqueness constraint but the product assumes it does. You record the gap, the query plan, and the single column the database will silently coerce. One brisk walkthrough is a sighting, not a design; but it prevents the team from launching a feature that registers the same customer twice with the serene confidence of a system that was never asked to disagree.

Words from the spaceship manual, translated

Request handler: A function that receives an incoming request, performs work, and returns a response. It is the doorway of a service, and like most doorways it will admit anything it is not explicitly taught to refuse.
Schema: The description of a database's tables, columns, types, constraints, and relationships. A schema is a contract the database enforces; the absence of a constraint is a constraint the database enforces just as firmly, in the direction of chaos.
Parameterised query: A query that separates code from data so the database cannot mistake a user's input for your instructions. It is the difference between "show me the row named X" and "show me the row, and also here are some instructions you didn't ask for."
Nullability: Whether a column may hold no value. A nullable column accepts silence; a non-nullable column demands an answer, and the database will refuse the row rather than improvise one.