A single server provides a forgiving environment. Everything lives in one place. The application, file storage, session data, and cron jobs all run on the same machine and can communicate with each other without much thought.
Then, when the product gains traction and one server is no longer enough, the team adds a second and then a third. This is usually treated as a straightforward scaling step: more servers means more capacity. In practice, however, it’s the point at which a few assumptions that worked well on one machine stop being true. Most teams don’t realize this until something breaks in production.
These are the issues I see most often.
Sessions that only exist on one server
If user sessions are stored in memory or in a local file on the server, they only exist on the server that handled the user’s login. The moment a load balancer sends the next request to a different server, the session disappears. Depending on how the application handles it, the user either gets logged out or ends up in a half-authenticated state.
This is one of the most common initial surprises because the issue is invisible until traffic actually starts splitting across servers. It worked perfectly in testing because testing occurred on one machine.
The solution is to store sessions in a shared, external location, such as a Redis instance or database table, so any server can access any user’s session. This is a small change in isolation, but it needs to happen before traffic is split, not after users start reporting random logouts.
Uploaded files that live on local disk
An application that saves uploaded files, including images and documents, to the local file system works fine on one server. However, on three servers, a file uploaded through one server is invisible to the other two. For example, a user uploads a profile picture and then refreshes the page, but the picture is gone because the refresh landed on a different server that never received the file.
This issue tends to surface later than session issues because file uploads are often a smaller percentage of traffic than logins, and the bug can remain hidden for a while before it’s noticed. When it is noticed, it is usually an unclear support ticket rather than an obvious server error.
The solution is to move file storage to a shared system, such as object storage like S3 or R2, or a network-attached storage volume mounted on all servers. This should be done before the third server goes into rotation and not as a fire drill after users start losing their uploads.
Cron jobs running more than once
A cron job that is scheduled to run every night on one server only runs once. The same cron job, configured identically, runs three times on three servers, unless something explicitly prevents that.
For some jobs, this is harmless and merely wasteful. For others, however, it’s a real problem. For example, a job that sends a daily summary email would now send three. A job that processes a queue might process the same items multiple times if it’s not designed to be safe under concurrent runs. A billing job that runs three times generates an uncomfortable conversation with a customer.
The solution is to either run all scheduled jobs from one designated server or to build in a locking mechanism so that only one instance of a job executes, even if multiple servers try to trigger it. This is worth auditing explicitly. It’s easy to add a second or third server and forget that cron jobs were never designed with this in mind.
Configuration and secrets drifting between servers
On one server, environment variables and configuration live in one place. Once there are three servers, each one needs the same configuration. Keeping them in sync manually is the kind of task that can easily be overlooked. For example, a deployment might update two servers but not the third. An API key is rotated on one server but not the others. A feature flag is set differently across the fleet because someone forgot which server they were on when they made the change.
This class of problem is particularly nasty because the symptoms are inconsistent and difficult to reproduce. The application works fine except when a user’s request lands on the one out-of-sync server, making it look like a random, unreproducible bug.
The solution is to centralize the configuration process through your deployment pipeline, a secrets manager, or infrastructure as code. This ensures that the configuration is defined once and applied identically everywhere, rather than existing independently on each machine.
Logs that are now scattered across three places
Debugging an issue on one server only requires looking at one log file. However, debugging an issue across three servers requires knowing which server handled the failed request and finding the correct log file on the appropriate machine.
This may sound like a minor inconvenience, but it becomes a major problem when you’re trying to diagnose an intermittent issue at 11 p.m. and realize you don’t know which server the failing request hit. Teams that haven’t planned for this end up SSHing into each server, searching through logs manually, which is slow and error-prone when speed matters most.
The solution is centralized logging, which involves shipping logs from all servers to one place, whether that’s a hosted service or a self-managed log aggregator. It’s best to set this up before you need it during an incident, not while you’re in the middle of one.
Database connections adding up faster than expected
A database has a maximum number of connections that it can handle. With one server and one application process, this rarely becomes an issue. However, add two more servers, each running the same number of application processes, and the total number of database connections can triple without anyone changing a single line of application code.
If no one has examined the connection pool settings or the database’s actual connection limit, mysterious “too many connections” errors will appear under load, often when real traffic hits all three servers simultaneously for the first time.
The solution is to review the connection pooling settings on each server to ensure the total number of connections remains within the database’s capacity. If the numbers are tight, consider using a connection pooler like PgBouncer. This five-minute check prevents genuinely confusing incidents.
What this adds up to
None of these problems are unusual. They’re all well understood and documented, and each has a simple solution. They still catch startups off guard because moving from one server to three feels like a scaling decision when it’s actually an architectural one. The assumptions that were safe to make on a single machine must be revisited deliberately before the second and third servers go live rather than being discovered one at a time in production.
Teams that handle this transition smoothly treat it as a checklist to work through before splitting traffic rather than a switch to flip and see what happens.