Backend

For a long time, building a web service was one undivided job. The code that decided what a page looked like and the code that pulled records out of storage sat in the same file, and one person edited both while scrolling from top to bottom. When a product had twenty pages, that was the faster way to work. Splitting it would have added ceremony without adding much.

Growth is what broke the arrangement, and it broke it on a specific point: when something went wrong, nobody knew where to look. At Pagedeck, Noa wrote up a set of meeting notes, hit save, and came back the next morning to find the last paragraph gone. Asked what happened, the team produced three different answers. Maybe the button never registered the click. Maybe it registered but the text never reached the server. Maybe it reached the server and the save itself failed. None of the three could be reproduced on anyone's own machine, so for three days nobody fixed anything — not because the bug was hard, but because no one owned the question.

The split that followed draws a line by where code runs. Everything that runs on the user's device — the browser tab, the phone app, the screen a person actually looks at and taps — is the frontend. Everything that runs on the company's own machines is the backend. Once that line exists, the three-way argument collapses into two clean questions with two clear owners. Did the button turn grey the instant it was clicked? That is a frontend question. Is the text genuinely stored, so that it opens again tomorrow on a different laptop? That is a backend question.

The two halves were worth separating because the work has a different shape on each side. A screen is drawn for one person at a time, and if it comes out wrong it can be drawn again a second later at no cost. A server takes thousands of requests at once, and a value written incorrectly stays wrong until somebody goes in and corrects it. A payment charged twice is not fixed by re-rendering anything. Someone has to find the records, refund one charge, and then change the ordering of operations so the same overlap cannot happen again next week.

The two halves meet at an API (application programming interface), an agreement fixed in advance about what two programs send each other and in what shape. The screen only needs to know the agreement; it never needs to know what happens inside. And because the agreement can be written down before either side is built, the frontend and the backend can be built the same week instead of one waiting on the other.

The terms filed under backend follow the path a single request takes from the moment it arrives to the moment a response goes out. What the path is made of is structure. What has to hold when requests overlap is principle. What breaks when it doesn't hold is risk. What the server remembers between one request and the next is state. Four branches.

Structure divides the inside of a server into layers. There are six pieces, and they fall into two groups: the first three build an answer while the caller waits, and the last three keep running after the answer has already gone out.

1. Server — the program that receives a request, processes it, and returns a response. What separates it from a program on a laptop is that it does not stop when nobody is watching; it stays up at four in the morning waiting for the one request that arrives then.
2. Business logic — the company's rules written as code. "A free plan can hold three documents" and "after a failed payment the account is read-only for seven days and locked on the eighth" live here. When a rule lives in a screen instead, the web app and the phone app eventually disagree about the same account.
3. Middleware — the layer that handles shared work between the request and the response. Confirming the caller is really signed in, recording who called what and when, and throttling anyone hammering the service a hundred times a minute all happen once, in one place, rather than being copied into twenty separate features.
4. Background job — work moved off the response. If exporting a 300-page document as a PDF takes forty seconds, nobody keeps the user in front of a blank screen for forty seconds. The request returns "we're preparing your file" immediately and a notification follows when the file is ready.
5. Message queue — a mechanism that lines work up and processes it asynchronously. When background work arrives in a burst, the queue holds it in order and hands it out at whatever rate the system can absorb. That's why 500 export requests at nine on a Monday morning do not take the service down.
6. Cron job — work that runs automatically at set times. Tallying yesterday's usage at three in the morning, generating invoices on the first of the month: anything that has to happen on a clock rather than in response to a person.

Principle covers the properties that keep results steady when requests overlap. Concurrency is the practice of making progress on several pieces of work at once — while one request waits on storage, the server handles another instead of sitting idle. That overlap is the only reason a single machine can serve thousands of people, and it is also the reason two requests can reach for the same value in the same instant. Idempotency is the property that sending the same request more than once produces the same result as sending it once. It's what keeps an impatient triple-click on a payment button, or an automatic retry after a dropped connection, from turning into three charges.

Risk is what surfaces when that overlap goes wrong. A race condition is a defect where the outcome depends on the order in which simultaneous operations happen to run. A workshop has one seat left and two people register in the same instant: both read "1 seat remaining," both are accepted, and the count lands at minus one. What makes this category nasty is that it might appear once in ten attempts. It never gets filed as a bug because nobody can reproduce it, and instead it comes back once a month as a refund request nobody can explain.

State is about what the server holds on to between requests. A session is the state a server keeps in order to remember a user, so that signing in once means not being asked again on the next request. Stateless is the opposite design: the server carries nothing across requests. This matters the moment the service grows past one machine. If the memory of a sign-in lives on machine one and the next request is routed to machine two, machine two treats the person as a stranger. So the memory moves out to shared storage that every machine can read, and the machines themselves stay empty and interchangeable.

The four branches pull on each other rather than sitting side by side. More users means more requests overlapping, which is what exposes race conditions; guarding against those calls for idempotent operations and for queueing; and absorbing the load by adding machines forces state out of the machines entirely. Every one of those judgments is made from what the database actually recorded, not from what anyone remembers happening.

"This looks like a backend problem. The screen said it saved, but nothing landed on the server."

The symptom showed up on a screen, which does not mean the cause is there — this hands the question, and the next debugging step, to the other side of the line.

"Let's move that calculation to the backend. If every screen computes it separately, web and mobile will drift apart."

One rule implemented in three places will eventually disagree with itself, so it should be computed once.

"This sprint is backend work, so there's nothing to demo. We open the interface first and wire up the screens next week."

A heads-up that a whole cycle will produce no visible output, and a request to stop measuring progress by screenshots.

At Pagedeck this is Theo's ground. When a new feature is agreed on, the first thing he produces is not code but a written description of the values that will cross the line: for document sharing, what gets sent when one person shares with another, what comes back when the sender lacks permission, what an expired link returns. From the day that document goes up, Noa builds the screens and Theo builds the server, and neither blocks the other.

The work does not end at launch. When Mia relays that four people wrote in this week saying saving "sometimes doesn't work," Theo goes to the records to find which requests actually failed. Three of the four clustered inside the same two minutes, and in each one somebody had the document open while somebody else deleted it. Nothing on a screen could have revealed that. It only becomes visible when the server's own log of events is laid out in order of time.

Grace asks about this area in roughly two ways. What does the server bill look like if usage grows tenfold, and can the current design absorb that tenfold without being rebuilt.

The most common mistake is assuming that because the backend has no screen, it has nothing to do with user experience. Everything a person sees is a screen, so the assumption is easy to make. But a large share of what users experience as slowness is the server taking time to assemble an answer. If opening a document list goes from 0.3 seconds to 2 seconds, not one line of screen code has changed, and yet people will say the app got sluggish. Teams that hold this belief spend two weeks polishing animations and come back with a product that feels exactly as slow as before, because the two seconds are still there. The fix sits on the other side of the line — an index on the query, a cached result, three round trips collapsed into one — and none of that shows up in a design review.

The second mistake is reading backend work as simple storage plumbing — take a value, save it, hand it back when asked. Looked at one feature at a time, that is honestly what it is. The difficulty comes from the same operation running thousands of times at once, from connections dropping halfway through, and from the same request arriving twice. Code that behaves perfectly for one user starts producing duplicate charges and vanished documents the moment a hundred people use it in the same minute. Believing otherwise wrecks estimates in a specific, repeating way: a feature scoped at three days turns into three weeks, and the extra time did not go into building the feature. It went into making the feature survive overlap.