Then traffic grows.
You add a second application instance behind a load balancer.
And suddenly strange things start happening.
Users get logged out.
Uploads disappear.
Background jobs cannot find temporary files.
One request sees state created by another server.
In the previous EvolvePHP post, I wrote about Evolve Audit.
Audit approaches an existing PHP application from the outside.
It asks:
“What can we learn about this codebase without running it?”
That is useful, but static evidence only tells part of the story.
At some point, modernization has to deal with the environment in which the application actually runs.
Which PHP version is active?
Are required extensions available?
Are important paths writable?
Are required environment variables present?
Do the assumptions in the project match the machine running it?
That is where I see Evolve Doctor fitting.
Redis.
Queues.
More servers.
Read replicas.
Containers.
Load balancers.
But infrastructure is only one part of the story.
A codebase that is difficult to reason about at small scale usually becomes more expensive to operate at large scale.
That is why I think scalability starts with coding principles long before it becomes an infrastructure problem.
A lot of architecture discussions eventually become arguments about deployment models.
Monolith or microservices?
One database or many?
Synchronous or event-driven?
PHP or Go?
Containers or serverless?
Those are useful questions.
But I think they often arrive too early.
Move the controller.
Move the business logic.
Create an API.
Deploy it separately.
Done.
Except the difficult part is usually not the code.
It is the data.
You can move code in a day. Untangling data ownership can take months.
That is why I think service extraction should begin with the database question much earlier than most teams expect.
“Which framework should we migrate to?”
The better first question is:
“What exactly are we dealing with?”
A mature PHP system can contain years of assumptions that are not obvious from looking at a few controllers.
Load balancers.
More servers.
Redis.
Read replicas.
Kubernetes.
Queues.
CDNs.
Those things matter.
Global state is convenient.
That is why it survives.
A static singleton is easy to reach.
A global helper saves a few lines.
A shared container gives you access to almost anything.
A lot of systems say they have observability because they have logs.
They do not.
Logs are useful, sometimes essential, but they are only one part of understanding what a system is actually doing.
A system can produce thousands of log lines every minute and still be nearly impossible to diagnose when something goes wrong.
A framework is supposed to help you build faster.
Routing, dependency injection, database access, queues, validation, authentication, caching, testing support—good frameworks remove huge amounts of repetitive work.
But there is another question I think framework design should take seriously:
What happens when the application eventually needs to move beyond the framework?
That might sound strange.
