Server

When programs ran only inside one person's computer, the only way several people could work on the same data was to pass files around. Someone writes up the meeting notes and emails them, the recipient edits and sends them back, and in the meantime a third person has edited the original. A few days later the same document exists in five versions and nobody is certain which is current.

The rules scattered the same way. If the company's decision that free users can create three documents lives copied inside everybody's program, changing that decision means visiting every machine. Whoever is still on an old copy keeps getting the old rule, and nobody can tell which people those are.

So a program that holds the data and the rules in one place, with everyone asking that place, became standard. One condition on that program determines most of the rest: it has to be able to receive a request whenever one arrives, which means it can't be switched off. That's the line separating it from a program you launch on a laptop and close when you're done, and nearly everything else about operating one follows from that single condition.

Four things.

1. It makes one copy of the truth. A document's current contents and who is allowed to see it exist in exactly one place, and the web app, the mobile app, and any external integration all ask that place. That's why raising the free-plan limit from three to five is one deployment. Clients stop being places where the truth can disagree.
2. It always receives. A request at three in the morning gets processed, and work that has to finish after the user closes the screen keeps running. This condition is also where the discipline of operations comes from. Something has to watch it, which is a job nobody has until the first outage.
3. It doesn't delegate judgment. Whether this person may view this document is decided by the server. Leave it to the code in the browser and anyone who bypasses that code faces no check at all. Any check that matters has to run on the side you control.
4. It takes on the heavy work. Turning a 300-page document into a PDF, or aggregating usage across 500 accounts, is not something a user's device does well.

The path one request takes is fairly fixed.

1. Receive the request.
2. Run the shared handling. The layer that confirms the caller is logged in, records who called what when, and briefly blocks callers who hammer it is middleware. Doing it in one layer is what keeps the same twenty lines out of twenty separate features.
3. Apply the rules. The part where company decisions are expressed as code is the business logic.
4. Read or write stored values. Where values actually persist is the database.
5. Return a response.

Some work doesn't end when the response goes out. Splitting a 40-second export away from the response is a background job, and the device that queues those up when many arrive at once is a message queue.

One design rule attaches from the beginning. If the server remembers anything between requests, adding a second server breaks it: a person who logged in on server one becomes a stranger when their next request reaches server two. So the memory lives in shared storage outside, and the server itself stays empty.

Four approaches solve the same problem differently.

1. Deploying functions only. Instead of keeping a server running, code executes when a request arrives — that's serverless. You pay for what you use and there's nothing to keep switched on, at the cost of the first request after a quiet stretch waiting for the environment to warm up.
2. Renting a managed backend. Login, storage, and basic queries come from a service someone else built. It's the fastest way to start, but complex rules have to be expressed inside whatever that service permits, which usually sends teams back to building their own at some point.
3. Keeping the rules in the client and using only storage. Fastest to build. But the rules sit on the user's device where they can be bypassed, and the same rules get implemented twice, once for web and once for mobile.
4. Having each device hold its data and reconcile with the others. Editing on a plane works, and the cost is deciding what survives when two people edit the same paragraph.

Three questions decide it: how complex the rules are, whether requests arrive steadily or pile into particular hours, and whether anyone is available to operate it. At a few requests a day, keeping something running is waste; at a steady high volume, keeping it running is the cheaper option. Shape matters more than volume here: a steady thousand requests an hour is easier to serve than a thousand of them at nine on Monday.

"This rule belongs on the server, not in the screen. The app is giving different answers."

Move where the judgment happens.

"The server holds the session, so we can't run two of them."

State has to move out before you can scale out.

"A server died overnight and nobody noticed. Let's wire up alerts first."

The requirement to stay running is the operational burden.

Pagedeck ran into this the week it tried to go from one server to two. Responses were slowing on Monday mornings when traffic peaked, so Theo added a second server — and from then on logins dropped at random, because login state was being held inside each server. Nothing in the code announced that the state was local; it simply was.

Moving it to shared storage took three days. After that, changing the server count became a single configuration line, and the setup switched to scaling up on Monday mornings and back down afterward. Building it empty from the start would have cost none of those three days.

The most common reading is that a server is a machine. A box in a rack comes to mind, so the assumption is natural. But the word names a program. Three server programs can run on one computer, and the same server program can be copied across ten computers. Read it as a machine and adding boxes looks like the only way to scale, while running several copies on one machine never comes to mind. The distinction surfaces the first time somebody says the server is at 40 percent CPU and means one of the two.

The other frequent belief is that adding servers fixes slowness. Sometimes it does, which is why it's the usual first attempt. But if the server holds state, adding one drops logins, and if the slow part is the database, ten servers only produce ten queues in front of the same storage. Measuring where the constriction actually is comes before adding anything.