Scalability Starts in the Code Before It Reaches the Infrastructure

When developers talk about scalability, the conversation often jumps quickly to infrastructure.

Load balancers.

More servers.

Redis.

Read replicas.

Kubernetes.

Queues.

CDNs.

Those things matter.

But I think one of the biggest mistakes we make is assuming that scalability begins when infrastructure becomes more sophisticated.

It usually begins much earlier.

It begins in the code.

Infrastructure can multiply capacity. It cannot permanently compensate for inefficient architecture.

If every request performs unnecessary work, adding servers simply lets you perform more unnecessary work at the same time.

A scaling problem can start with one innocent request

Imagine an endpoint that returns a customer's dashboard.

At first, the application has 100 users.

The request does something like:

Load customer
Load subscriptions
Load invoices
Load payments
Calculate totals
Load notifications
Call external API
Render response

Everything feels fine.

Then traffic grows.

Now that same request is executed thousands of times.

Maybe every dashboard visit runs 30 database queries.

Maybe the external API is called every time even though the result changes once per hour.

Maybe historical totals are recalculated from thousands of rows for every request.

The application may still work.

But its cost grows directly with traffic.

Eventually someone says:

“We need more servers.”

Maybe you do.

But first I would ask:

Why does one request cost this much?

The cheapest scaling improvement is often doing less work

Suppose one request takes:

Database queries: 40
External calls: 3
CPU-heavy calculation: 1
Response time: 800ms

Now imagine reducing that to:

Database queries: 8
External calls: 0
Cached calculation: 1
Response time: 150ms

You have changed the scaling characteristics of the system before touching the infrastructure.

That is why performance and architecture are closely related.

Good scaling often means reducing the amount of work required per unit of traffic.

Query design matters early

Databases are usually one of the first places bad scaling assumptions become visible.

A feature may work perfectly during development with 500 records.

Then production contains 20 million.

This query:

SELECT *
FROM orders
WHERE customer_id = ?
ORDER BY created_at DESC;

may be fine.

Until the right index does not exist.

Or until the application loads all rows when it only needs twenty.

Or until every row triggers another ORM query.

The famous N+1 problem is a good example.

This:

Load 100 orders
    ↓
Load customer for each order

can quietly turn one logical operation into 101 database queries.

No amount of elegant controller code makes that scalable.

Understanding data access is part of designing the feature.

Data structures matter too

Scalability is not only about databases.

Sometimes code itself grows badly with input size.

Imagine checking whether every user appears in another list.

A simple implementation might repeatedly scan the entire list.

With ten users, nobody cares.

With ten million comparisons, suddenly the algorithm matters.

You do not need to turn every business application into a computer science exercise.

But developers should understand one basic question:

What happens to this code when the amount of data becomes 10x or 100x larger?

That question alone catches a surprising number of problems.

Blocking work should be questioned

Another common scaling issue is doing everything inside the user's request.

Imagine checkout performs:

Save order
Charge payment
Generate PDF invoice
Resize uploaded images
Send confirmation email
Notify analytics platform
Call CRM
Send webhook
Return response

Some of those operations may genuinely belong in the request.

Others may not.

If the user does not need the work completed before receiving the response, it may belong in a background job.

The request path might become:

Validate
Save order
Charge payment
Queue follow-up work
Return response

Now the user waits for less work.

And the system can process asynchronous workloads separately.

Queues are infrastructure, but the decision to separate synchronous and asynchronous responsibility is an architectural decision.

Stateless code scales more easily

Horizontal scaling becomes much simpler when any application instance can handle any request.

But that depends heavily on how state is managed.

Suppose server A stores temporary user state in process memory.

The next request reaches server B.

Now the state is missing.

Teams often discover this only after adding a second server.

The infrastructure did not create the problem.

It exposed an assumption already present in the code.

The same thing happens with:

• local filesystem sessions,
• static mutable state,
• in-memory caches treated as authoritative,
• background jobs depending on request-local state,
• application instances owning information they should not own.

Designing state deliberately makes future scaling much easier.

Caching cannot fix unclear ownership

Caching is another area where scalability discussions quickly become infrastructure discussions.

“Add Redis.”

Sometimes that helps.

But before caching something, I want to understand:

What is the source of truth?
How stale can this value become?
What invalidates it?
Who owns invalidation?
What happens if the cache disappears?

Without those answers, the cache can become a second database with worse consistency rules.

Good caching begins with understanding the data.

Clear boundaries help systems scale selectively

Suppose an application contains:

Accounts
Orders
Billing
Reporting
Notifications

Now Reporting becomes extremely expensive.

If the architecture has reasonable boundaries, you may be able to scale Reporting differently.

Maybe its jobs get dedicated workers.

Maybe its database reads use replicas.

Maybe it eventually becomes an independent service.

But if everything shares implementation details and data freely, scaling one capability independently becomes difficult.

This is one reason modular architecture matters even before microservices enter the conversation.

Good boundaries give you more scaling options later.

Measure before redesigning

There is also an opposite mistake:

designing complicated architecture because you imagine huge traffic in the future.

That usually creates complexity before there is evidence that the complexity is needed.

I prefer something closer to:

Build simply
    ↓
Measure
    ↓
Identify pressure
    ↓
Optimize the expensive path
    ↓
Scale the necessary component

Observability matters here.

Without measurements, performance discussions become guesses.

You need to know:

• slow endpoints,
• expensive queries,
• queue latency,
• cache hit rates,
• dependency latency,
• error rates,
• resource usage.

Then you can respond to real pressure.

Scaling is a chain

I tend to think about scalability in layers:

Efficient code
    ↓
Efficient data access
    ↓
Clear state ownership
    ↓
Async where appropriate
    ↓
Caching where justified
    ↓
Horizontal scaling
    ↓
Specialized infrastructure

You might eventually need every layer.

But skipping directly to the bottom rarely fixes weaknesses at the top.

Frameworks cannot make bad assumptions scalable

Laravel, Symfony and other mature PHP frameworks already provide powerful scaling tools.

Queues.

Caching.

Database connections.

Events.

Workers.

Middleware.

Scheduling.

But the framework cannot decide whether your request performs unnecessary work.

It cannot automatically decide which business operation should be asynchronous.

It cannot determine whether your data ownership makes sense.

It cannot know whether your cache invalidation strategy is correct.

Those are engineering decisions.

Scalability is really about growth without collapse

A scalable system is not simply one that can run on many servers.

It is one whose design allows capacity to grow without complexity growing uncontrollably with it.

Sometimes that requires more infrastructure.

Sometimes it requires fewer queries.

Sometimes it means moving work out of the request.

Sometimes it means changing an algorithm.

Sometimes it means fixing a boundary.

And sometimes the best scaling improvement is deleting work the system never needed to perform in the first place.

So before asking:

“How do we scale this application?”

I think it is worth asking something simpler:

“What exactly does the application do for one request, and how much of that work is actually necessary?”

That is often where scalability really starts.

The Hidden Cost of Global State in PHP

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 static “current user” or “current tenant” feels harmless when every request starts in a fresh PHP process.

And for years, that model worked reasonably well because PHP-FPM gave developers something valuable for free:

process termination cleaned up the mess.

But once PHP applications start living longer, the cost of global state becomes much easier to see.

Why global state feels harmless

Imagine code like this:

CurrentTenant::set($tenant);

Later:

$tenant = CurrentTenant::get();

Simple.

No need to pass tenant context through several layers.

No need to redesign service interfaces.

The problem is that this convenience hides ownership.

Who set it?

Who is allowed to change it?

When does it stop being valid?

Who clears it?

What happens when another execution starts?

Those questions are easy to ignore in short-lived request models.

They become much harder to ignore in persistent ones.

The old PHP lifecycle hid a lot

Traditional PHP applications often behave roughly like this:

Request arrives
    ↓
PHP process handles request
    ↓
Response returned
    ↓
Request state disappears

Even if some code accidentally leaves state behind, the process lifecycle often resets everything.

That creates a kind of accidental safety.

Now consider:

Worker boots once
    ↓
Execution A
    ↓
Execution B
    ↓
Execution C
    ↓
Execution D

Suddenly:

CurrentUser::$user
CurrentTenant::$tenant
DatabaseContext::$transaction
TelemetryContext::$trace

may survive longer than expected.

If cleanup is incomplete, Execution B can inherit assumptions from Execution A.

That is not just messy architecture.

It can become a correctness or security problem.

The dangerous part is invisibility

Global state creates dependencies that often do not appear in function signatures.

Suppose this method looks simple:

public function calculateInvoice(Order $order): Invoice

But internally it reads:

CurrentTenant::get();
CurrentUser::get();
CurrencyContext::get();
FeatureFlags::current();

The real dependency graph is much larger than the method tells you.

That makes the code harder to:

• test,
• reason about,
• reuse,
• run concurrently,
• move into another process,
• isolate by tenant,
• execute safely in long-running workers.

The function signature says one thing.

The runtime reality says another.

That mismatch is where a lot of complexity hides.

Global state makes concurrency harder

Even if your PHP application does not use threads, concurrency still matters.

Async runtimes, Fibers, workers and interleaved tasks can all expose assumptions that were invisible before.

Imagine:

Task A → Tenant A
Task B → Tenant B

If both rely on the same mutable global:

CurrentTenant::set(...)

you now have a race over shared context.

The exact implementation may differ depending on the runtime, but the architectural problem is the same:

execution-specific data is stored somewhere broader than the execution itself.

That is a lifetime mismatch.

Globals also complicate testing

Global state can make tests appear order-dependent.

One test runs:

CurrentUser::set($admin);

The next test assumes no user is set.

If cleanup is incomplete, the second test fails.

Or worse, it passes for the wrong reason.

This is why some test suites only work when run individually but fail in random order.

The test runner is exposing the same problem that a long-running runtime eventually will:

state escaped its intended lifetime.

Static does not always mean bad

It is important not to overcorrect.

Not every static method or global value is dangerous.

This:

Uuid::fromString($value);

is very different from:

CurrentUser::set($user);

The first is essentially behavior.

The second stores mutable execution state.

The issue is not the static keyword itself.

The more useful question is:

Does this value change between executions?

If yes, then its lifetime matters.

Configuration loaded once at boot may legitimately be application-scoped.

The current user probably is not.

The current tenant probably is not.

The active transaction definitely is not.

Lifetime should match meaning

One useful way to think about state is:

Application lifetime
Execution lifetime
Transient lifetime

Application state might include:

configuration
immutable metadata
service definitions
shared infrastructure clients

Execution state might include:

current request
current user
current tenant
trace context
transaction context

Transient state exists only while one operation is being performed.

Problems begin when something with execution meaning is stored in application lifetime.

That is how stale state survives.

Passing everything everywhere is not the answer

The alternative to global state is not necessarily turning every method into this:

process(
    $request,
    $user,
    $tenant,
    $transaction,
    $trace,
    $locale,
    $timezone,
    $featureFlags
);

That can become ugly too.

Good architecture usually gives execution context a clear home.

For example:

ExecutionContext

might contain the state that belongs to one execution.

Services that genuinely need that context can depend on it explicitly.

Other services do not.

The important point is not the exact class design.

It is that ownership and lifetime become visible.

Cleanup matters as much as construction

Persistent systems often focus on setup:

start execution
attach context
open transaction
start trace

But safe reuse depends just as much on the end:

finish execution
close transaction
flush telemetry
release references
clear execution context
verify reusable state

If cleanup fails, blindly reusing the process may be unsafe.

That is why I think cleanup should be treated as part of execution correctness, not as an optional housekeeping step.

This is one reason EvolvePHP treats execution as a first-class concept

One of the ideas behind EvolvePHP's runtime model is that application lifetime and execution lifetime should not be confused.

A long-running process may survive thousands of executions.

The user should not.

The tenant should not.

The transaction should not.

The trace should not.

Execution-specific state should belong to the execution and be cleaned up with it.

And if cleanup cannot be trusted, the safer choice may be to stop reusing that process.

That is more conservative than assuming everything is fine.

I think persistent runtimes need that conservatism.

Global state is often technical debt disguised as convenience

Global state saves effort at the point where it is introduced.

The cost arrives later.

It appears when:

• tests become unpredictable,
• modules become difficult to isolate,
• background jobs reuse stale context,
• tenant information leaks,
• concurrent tasks interfere,
• services become difficult to extract,
• persistent workers behave strangely.

The difficult part is that the original line of code looked completely reasonable.

That is why this problem survives.

Global state is rarely expensive on day one.

It becomes expensive when the system starts changing.

And in long-lived PHP applications, change is exactly what the architecture needs to survive.

Observability Is Not Logging

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.

The real question is:

Can you understand the internal state of the system from the signals it produces?

That is what observability is really about.

Logs tell you what happened

A typical application might log:

User logged in
Order created
Payment failed
Queue job started
Queue job completed
Database timeout

Useful.

But when production is failing, those messages often leave important questions unanswered.

For example:

Why did checkout become slow?

Which dependency caused it?

Was the slowdown isolated to one tenant?

Did a retry make the problem worse?

Was the request blocked on the database?

Did the queue backlog first?

Which deployment introduced the change?

Logs may contain pieces of the answer.

Observability should help connect them.

The three signals are not enough by themselves

People often describe observability as:

Logs
Metrics
Traces

That is a useful model, but simply collecting all three does not automatically make a system observable.

You can have millions of metrics and still not know what happened.

You can have distributed traces that nobody can interpret.

You can have perfect logs with no useful context.

The important part is the relationship between the signals.

A request might look like:

HTTP Request
    ↓
Authentication
    ↓
Order Service
    ↓
Database
    ↓
Payment API
    ↓
Queue

If something takes 4.7 seconds, I want to know where those 4.7 seconds went.

That is where tracing becomes powerful.

Context is what turns data into evidence

Imagine seeing this log:

Payment provider timeout

Now compare it with:

execution_id: 9f73...
tenant: acme
order: ORD-18291
provider: stripe
attempt: 2
duration: 4.8s
trace_id: 7ab1...

The second message is not just more detailed.

It connects that event to a specific execution.

Now other telemetry from the same request, queue job or worker task can be correlated.

That is much more useful.

Observability becomes harder in long-running systems

Traditional PHP has an interesting advantage.

The process usually dies after the request.

That naturally destroys request-specific state.

Long-running workers change that.

Imagine a worker processing:

Execution 1 → Tenant A
Execution 2 → Tenant B
Execution 3 → Tenant C

If telemetry context from Execution 1 leaks into Execution 2, your monitoring system may confidently report the wrong tenant, user or trace.

That is worse than missing telemetry.

It is misleading telemetry.

In persistent runtimes, observability needs lifecycle discipline too.

Context should begin with the execution.

And it should end with the execution.

Errors are not the only thing worth observing

A mature system should help answer questions before everything fails.

For example:

Are requests becoming slower?

Is memory usage gradually increasing?

Are retries rising?

Is one dependency getting slower?

Are queue jobs taking longer?

Are workers being recycled more often?

Are database connections failing?

Are cleanup failures occurring?

These are often early signals.

By the time users report the outage, the system may have been warning you for hours.

Good observability helps turn those warnings into something engineers can act on.

Architecture should be observable too

This is an area I think deserves more attention.

Most observability platforms focus heavily on runtime performance.

That is important.

But architecture has runtime consequences too.

Imagine being able to see:

Module dependency violations

Unexpected cross-module calls

Execution-scoped services retained too long

Cleanup failures

Quarantined workers

High retry rates on one capability

Persistent memory growth

Unexpected data ownership crossings

Those signals tell you more than whether CPU usage is high.

They tell you when architectural assumptions are starting to break down.

This influences how I think about EvolvePHP

Observability is one of the areas I want EvolvePHP to treat as part of application architecture, not as something bolted on afterward.

That means thinking about:

• execution identifiers,
• structured observations,
• trace context,
• metrics,
• lifecycle events,
• module boundaries,
• cleanup outcomes,
• persistent-runtime diagnostics.

The idea is not that EvolvePHP should replace tools like OpenTelemetry or existing monitoring platforms.

Quite the opposite.

The framework should make it easier to produce useful evidence that those tools can consume.

A framework understands things that an external monitoring tool may not.

It knows when an execution starts.

It knows which module is running.

It knows when cleanup succeeds.

It knows when a process has become unsafe to reuse.

Those are valuable signals.

Observability should reduce uncertainty

When production breaks at 2 AM, nobody wants more dashboards.

They want answers.

What changed?

Where did the failure start?

Who was affected?

Was the problem local or systemic?

Can the process continue safely?

Did retrying make things worse?

What should we fix first?

That is the standard I think observability should be judged by.

Not how many logs the system produces.

Not how many charts appear on a dashboard.

But how quickly the telemetry turns uncertainty into understanding.

Logging records events.

Observability helps explain the system.

Why Frameworks Should Help You Leave Them

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.

Why should a framework make it easier to leave?

Because long-lived software changes.

And if a framework becomes impossible to separate from the application, it can eventually become part of the problem it once solved.

Framework lock-in is not always bad

Some lock-in is reasonable.

If you choose a framework, you are choosing conventions, APIs and abstractions.

You should benefit from them.

Trying to hide every framework feature behind another abstraction often creates unnecessary complexity.

I don't think developers should build applications as if they are planning to replace their framework next Tuesday.

But there is a difference between:

“This application uses Laravel.”

and:

“This application cannot express its business rules without Laravel internals.”

The first is normal.

The second becomes expensive when the system gets old.

Business logic should survive framework change

Imagine a billing rule:

Customers on the Enterprise plan
receive a 7-day grace period before suspension.

That rule might live for ten years.

During that time, the application could move through:

Framework version A
      ↓
Framework version B
      ↓
New database layer
      ↓
Queue redesign
      ↓
Different runtime
      ↓
Partially extracted service

The business rule should still mean the same thing.

If it is deeply buried inside controller methods, ORM lifecycle hooks, global helpers and framework events, understanding or moving it becomes much harder.

The framework should help execute the business logic.

It should not become the business logic.

Good boundaries make migration boring

Suppose Orders depends directly on dozens of framework facilities:

Controller
   ↓
ORM model
   ↓
Global helpers
   ↓
Static auth state
   ↓
Framework event bus
   ↓
Framework queue

Now imagine extracting Orders into another process.

You do not just move Orders.

You move all the assumptions surrounding it.

Compare that with:

HTTP
  ↓
Order Application Service
  ↓
Order Domain
  ↓
Explicit Interfaces
  ↓
Framework Adapters

The second design does not guarantee painless migration.

Nothing does.

But it gives you places where change can happen.

The database implementation can change behind a contract.

The queue transport can change.

The HTTP adapter can change.

The application rules remain easier to reason about.

That is architectural optionality.

Frameworks should expose boundaries, not hide everything

One temptation in framework design is to make everything feel magical.

Auto-discovery.

Global state.

Implicit dependencies.

Automatic bootstrapping.

Invisible lifecycle behavior.

These features can make the first week incredibly productive.

But implicit architecture becomes harder to understand after several years.

I prefer frameworks that make important boundaries visible.

For example:

Who owns this service?
When is it created?
How long does it live?
Who resets it?
Who owns this data?
Which module depends on which?
What happens if this capability moves elsewhere?

You do not need ceremony everywhere.

But the things that affect long-term architecture should be understandable.

Interoperability matters

One way frameworks can reduce lock-in is by respecting ecosystem standards.

In PHP, PSR interfaces are useful partly because they create shared boundaries between libraries and frameworks.

If your HTTP components, logging, caching or container integration can speak common interfaces, replacing one implementation becomes more realistic.

Interoperability also matters when integrating existing systems.

A modernization project should not always require:

Old Application
      ↓
Complete Rewrite
      ↓
New Framework

Sometimes the better path is:

Existing Application
      ↔
New Capability
      ↔
Gradual Migration

The ability to coexist can be more valuable than the ability to replace.

Leaving does not always mean replacing the whole framework

This is important.

An application does not need to “leave” a framework completely.

Maybe only Reporting needs to move.

Or Notifications.

Or a high-concurrency worker.

Or a payment capability that needs stronger isolation.

A mature system may eventually look like:

Main PHP Application
├── Customers
├── Orders
├── Admin
└── Catalog

Separate Services
├── Reporting
└── Notifications

That is still a framework application.

It simply stopped requiring every workload to live inside the same runtime.

A framework that supports healthy boundaries makes this much easier.

Upgrades are also a form of leaving

There is another kind of migration developers sometimes overlook.

Moving from one major framework version to another can resemble a small migration.

APIs disappear.

Configuration changes.

Packages become incompatible.

Runtime assumptions change.

If application code is tightly coupled to every framework detail, even upgrades become dangerous.

That is why good architecture can help even if the framework is never replaced.

You are preserving the ability to move between versions of the same ecosystem.

This influences how I think about EvolvePHP

One principle I keep returning to while building EvolvePHP is:

The framework should not require permanent architectural dependence in exchange for short-term productivity.

That influences several areas:

• explicit module boundaries,

• contracts around infrastructure,

• interoperability,

• execution lifecycle visibility,

• incremental modernization,

• Bridge-based coexistence,

• selective extraction.

The goal is not to make EvolvePHP irrelevant.

The goal is to make applications stronger than their dependency on EvolvePHP.

If a future team decides that one capability belongs somewhere else, the architecture should help rather than resist them.

The best framework relationship should not feel like captivity

A framework can provide enormous value for many years.

It can shape how teams work.

It can reduce complexity.

It can make good practices easier.

But the application ultimately belongs to the business, not to the framework.

That means the architecture should preserve some freedom.

Freedom to upgrade.

Freedom to replace an infrastructure component.

Freedom to extract a module.

Freedom to integrate another runtime.

And, if necessary, freedom to migrate away completely.

A framework that makes leaving possible is not weakening its value.

It is respecting the lifetime of the software built on top of it.

Can a PHP Application Be Designed for 10–20 Years of Change?

Most applications are not designed with a ten-year lifespan in mind.

They are built to solve the immediate problem.

Ship the product.

Get users.

Add features.

Then, somewhere along the way, the application becomes important enough that replacing it is no longer simple.

Ten years later, the business may still depend on it.

But the framework has changed.

The infrastructure has changed.

The team has changed.

The database has grown.

The original developers may be gone.

And suddenly the question becomes:

Can this system keep evolving without needing a complete rewrite?

I think that is one of the most important architectural questions we can ask.

Long-lived software has a different problem

When an application is expected to live for years, technical decisions behave differently.

A dependency that looks convenient today may become a migration problem later.

A framework-specific API used everywhere may make future upgrades much harder.

A database table shared across ten unrelated features may become impossible to separate.

A global helper that saves time today may become invisible coupling tomorrow.

The problem is not that any of these decisions are automatically wrong.

The problem is accumulation.

Small shortcuts become structural assumptions.

And structural assumptions are expensive to change.

Stability does not mean avoiding change

Designing for longevity does not mean freezing the architecture.

It means making change less dangerous.

A ten-year-old application should not look exactly like it did in year one.

It should evolve.

That might mean:

PHP version changes
Framework upgrades
Database changes
Infrastructure changes
New deployment models
New security requirements
New integrations
New business capabilities

The goal is not to predict all of those changes.

You cannot.

The goal is to avoid making today's decisions impossible to undo.

Boundaries matter more than predictions

Suppose an application contains:

Customers
Orders
Billing
Reporting
Notifications

If all five areas share the same internal state, database logic and framework services directly, future change becomes expensive.

But if each capability has clearer responsibilities and explicit interfaces, the system has more room to evolve.

Billing can change without Reporting knowing every internal detail.

Notifications can move to a queue without rewriting Orders.

Reporting can eventually become a separate service if that becomes useful.

You do not need to know today which of those things will happen.

You only need enough separation to make them possible later.

That is what good boundaries buy you.

Framework coupling deserves attention too

Every framework gives you useful abstractions.

Routing.

Dependency injection.

ORMs.

Queues.

Events.

Authentication.

Caching.

Those are valuable.

But if your business logic depends directly on framework internals everywhere, the framework effectively becomes part of every domain decision.

That makes future replacement harder.

I am not arguing for hiding the framework behind abstractions everywhere.

That can become pointless architecture.

But business rules that matter for ten years should not be impossible to understand outside a specific controller, ORM model or helper function.

The more important the business capability, the more useful it is to keep its core rules explicit.

Data usually outlives code

Code gets rewritten surprisingly often.

Data does not.

A ten-year-old application may contain:

millions of records
historical transactions
customer documents
audit history
integration identifiers
business corrections
legacy states

That data becomes part of the company's history.

So long-lived architecture needs to think seriously about ownership.

Which capability owns which data?

Who is allowed to write it?

What happens when schemas evolve?

How do older records remain understandable?

How do migrations roll back?

A framework upgrade may take weeks.

A bad data migration can create problems that last years.

Tests become institutional memory

One of the biggest risks in old systems is losing the reason behind behavior.

You might see code like:

if ($customer->createdBefore('2019-04-01')) {
    // special calculation
}

Ten years later, nobody remembers why.

Maybe it is obsolete.

Maybe removing it breaks a contractual rule for thousands of customers.

Tests can preserve some of that knowledge.

Not just unit tests.

Behavioral tests around important business outcomes.

Those tests become executable documentation for future developers.

They help answer:

“What must still work after we change this?”

For long-lived software, that is extremely valuable.

Operational knowledge also matters

Architecture is not only source code.

A system that is easy to understand but difficult to deploy is still difficult to change.

Long-lived applications benefit from:

repeatable deployments
observable failures
documented dependencies
health checks
clear rollback procedures
automated quality gates
known runtime requirements

The fewer things that exist only in one engineer's memory, the safer the system becomes over time.

Avoid designing for imaginary futures

There is a trap here.

Trying to design for twenty years can easily turn into overengineering.

You do not need ten abstraction layers because something might change in 2034.

You do not need microservices because the company might become large.

You do not need adapters around every standard library call.

Designing for change should not mean designing for every possible future.

It means being careful with decisions that are difficult to reverse.

That is a much smaller and more practical goal.

This is one of the ideas behind EvolvePHP

When I think about EvolvePHP, one of the questions I keep returning to is:

What would make an application easier to evolve five or ten years from now?

That is why the framework direction emphasizes:

• modular boundaries,

• explicit contracts,

• controlled service lifetimes,

• observable execution,

• incremental modernization,

• interoperability,

• selective extraction.

I do not expect a framework to make an application future-proof.

Nothing can.

But a framework can either make future change easier or make itself another obstacle.

I want EvolvePHP to lean toward the first.

The real measure of architecture

Good architecture is often demonstrated on the day something is built.

I think the harder test comes years later.

Can another developer understand the boundaries?

Can one capability change without destabilizing everything?

Can dependencies be upgraded?

Can infrastructure evolve?

Can part of the system be replaced without replacing all of it?

Can the application survive developers, technologies and business models changing around it?

If the answer is yes, then the architecture has done something valuable.

Because the best long-term architecture is not one that predicts the future.

It is one that leaves enough room for the future to be different.

When Should a Modular Monolith Become Microservices?

A modular monolith can take you surprisingly far.

You can have clear business boundaries, independent modules, explicit contracts, good tests, background workers, queues, caching, horizontal scaling and strong deployment automation without splitting the application into separate services.

So at what point should one of those modules actually become a microservice?

I don't think the answer is:

“When the application gets big.”

And it definitely isn't:

“When we reach enough users.”

The better question is:

What problem would independent deployment solve that the modular monolith can no longer solve well?

That distinction matters.

Start with a real boundary

Suppose an application contains:

Customers
Orders
Billing
Reporting
Notifications

Inside a modular monolith, these can already be separate architectural units.

They may have their own services, domain rules, tests and public contracts while still running inside one application.

That means:

Module boundary ≠ Service boundary

A module says:

“This capability owns this responsibility.”

A service adds another decision:

“This capability should also run and deploy independently.”

That second decision comes with significant cost.

So there should be evidence for it.

Signal 1: Independent scaling

Imagine Reporting becomes dramatically more expensive than the rest of the application.

A few large customers begin generating millions of records and running heavy analytics.

Now you might have:

Customers    normal load
Orders       normal load
Billing      normal load
Reporting    20x workload

Scaling the entire application just to handle Reporting may become wasteful.

If Reporting already has a clean boundary, moving it into a separately scalable service starts to make sense.

This is a good extraction signal because there is a measurable problem.

Signal 2: Independent deployment becomes valuable

Suppose Billing must change frequently because payment providers, tax rules or compliance requirements keep changing.

But every Billing deployment currently requires releasing the entire application.

That may eventually create unnecessary coordination.

If Billing has:

• a clear API,

• clear data ownership,

• good tests,

• independent operational requirements,

then independent deployment may become valuable.

Again, the reason is not “microservices are better.”

The reason is that deployment coupling has become expensive.

Signal 3: Team ownership changes

Architecture often follows organizations.

When five developers work on the same application, a single deployment model may be perfectly manageable.

When several teams independently own Customers, Billing, Reporting and Notifications, coordination pressure increases.

At some point, this:

Team A ─┐
Team B ─┼── one deployment
Team C ─┘

may become a bottleneck.

A service boundary can allow a team to own its capability more independently.

But I would still resist splitting purely because teams exist.

The business boundary should already be healthy before distribution makes it stronger.

Otherwise you simply turn internal coupling into network coupling.

Signal 4: Security or compliance needs stronger isolation

Sometimes a capability genuinely needs a stronger boundary.

Payments may need different access controls.

Sensitive documents may require stricter infrastructure.

A regulated workload may require separate audit, deployment or operational policies.

Now process or network isolation may provide something the in-process module cannot.

This is one of the stronger reasons to extract because the boundary is driven by an actual security or compliance requirement.

Signal 5: The runtime requirements are genuinely different

Maybe most of your platform works perfectly well in PHP.

But one capability eventually needs something very different.

Perhaps a worker needs extreme concurrency.

Maybe image processing is CPU-heavy.

Perhaps another ecosystem provides a substantially better tool for a specific workload.

With a good modular architecture, you might eventually have:

PHP Application
├── Customers
├── Orders
├── Billing
└── Reporting

          ↓

Specialized Processing Service
          Go / Rust / PHP

The important part is that the extraction is local.

You don't rewrite the application because one workload changed.

What is not a strong reason?

I would be cautious about extracting because:

"The codebase is getting large."
"We might scale one day."
"Big companies use microservices."
"We want Kubernetes."
"Services look cleaner."

Those may describe future possibilities.

They do not necessarily describe current problems.

Microservices introduce their own architecture:

• network failures,

• retries,

• idempotency,

• authentication between services,

• distributed observability,

• deployment coordination,

• message/version compatibility,

• data consistency,

• operational overhead.

Before extraction, most of those problems may not exist.

After extraction, they become your responsibility.

Data ownership is the hardest test

Before I extract a module, I would ask one particularly uncomfortable question:

Can this capability genuinely own its data?

Suppose Billing is extracted but still directly reads and writes twenty tables owned by Orders and Customers.

You haven't really created an independent service.

You have created a distributed application sharing a database.

Sometimes that is an acceptable intermediate step.

But it should be recognized as one.

A stronger boundary looks more like:

Orders owns order state
Billing owns payment state

Orders → Billing contract
Billing → Orders contract

Ownership becomes explicit.

Extraction should be earned

The progression I prefer is:

Monolith
   ↓
Modular Monolith
   ↓
Observe real pressure
   ↓
Identify one boundary
   ↓
Prove independent ownership
   ↓
Extract if the benefit exceeds the cost

That gives the architecture time to tell you where distribution is actually useful.

It also means some modules may never become services.

That is completely fine.

A successful modular monolith does not have to “graduate”

This is probably the biggest misconception.

A modular monolith is not necessarily an intermediate architecture waiting to become microservices.

It may be the correct long-term architecture.

And if one capability eventually deserves independent deployment, you should be able to extract that capability, not redesign the entire system.

That is the architectural direction I care about with EvolvePHP as well:

start modular, preserve boundaries, measure pressure, and extract selectively.

The question should never be:

“Are we big enough for microservices?”

It should be:

“What concrete problem becomes easier if this particular boundary becomes independently deployable?”

If there isn't a strong answer yet, the module can probably stay exactly where it is.

EvolvePHP 2 Reaches Its First Alpha — The Framework Is Becoming Real

This is a milestone I have been looking forward to for a while.

EvolvePHP 2.0.0-alpha.1 is officially out.

Until now, most of what I have written about EvolvePHP has focused on architecture: modular applications, execution isolation, long-running PHP, modernization, Bridge, service lifetimes and designing software for change.

With this release, those ideas are no longer only plans.

There is now a tagged, testable EvolvePHP 2 Alpha.

It is still experimental. APIs can change. It is not production-ready.

But it is real.

The first Alpha was published on September 13, 2026, targeting the 2.x line.

What has actually been built?

Quite a lot of the foundation is now implemented.

The Alpha includes:

• a runtime-neutral Core with configuration, service registration, Application/Execution/Transient service lifetimes, execution scopes, deterministic reset and execution orchestration;

• a PSR-based HTTP foundation with middleware, routing, dispatch, health handling and explicit response-resolution/emission boundaries;

• module and plugin foundations with dependency/capability graphs, lifecycle orchestration, restricted service registration and Composer-based plugin discovery;

• Evolve Doctor diagnostics and development tooling;

• read-only Evolve Audit foundations and adoption-planning declarations;

• embedded Bridge foundations for PSR, Laravel and Symfony;

• remote HTTP/JSON Bridge support, including an isolated PHP 7.4-compatible legacy client;

• an application skeleton with explicit CLI, route configuration and module/plugin generators.

One area I am particularly pleased with is the execution model.

EvolvePHP already distinguishes between:

Application
Execution
Transient

An HTTP request, CLI command or other execution can receive its own execution scope. Cleanup/reset results remain separate from the business operation result, which gives future runtimes enough information to decide whether a process is still safe to reuse.

That foundation is important for where EvolvePHP is going.

Modernization is also present in the Alpha

The modernization direction is no longer only an RFC.

Evolve Audit can inspect existing PHP source and Composer evidence without executing the target application.

Adoption planning can record ownership, compatibility requirements, migration evidence and rollback evidence.

Bridge can then support a capability that needs to coexist with an existing application.

For compatible environments, embedded integration can use PSR, Laravel or Symfony adapters.

Where PHP versions or dependency graphs cannot safely coexist, Remote Bridge provides a process boundary instead. The legacy remote client has a deliberately isolated PHP 7.4 compatibility boundary while EvolvePHP 2 itself continues to require PHP 8.4.

The principle remains:

Understand
   ↓
Plan ownership
   ↓
Integrate
   ↓
Move one capability
   ↓
Validate

Not:

Rewrite everything

How can you try Alpha 1?

There is an important limitation here.

The first-party packages are not yet independently published, and public composer create-project installation is not available yet.

So I do not want to pretend this is already the normal end-user installation experience.

For now, Alpha 1 is a source preview.

Developers who want to inspect or contribute to the framework can clone the repository:

git clone https://github.com/josiahking/evolvephp.git
cd evolvephp
composer install
composer quality

The repository also contains the accepted application skeleton and dedicated Alpha documentation. The skeleton already owns explicit route and CLI configuration, with doctor and route:list as its baseline commands. Development tooling also provides module:new and plugin:new when DevTools is available.

For example, the generators are designed around explicit application-owned components:

module:new Billing
    ↓
src/Modules/Billing/

plugin:new Cache
    ↓
src/Plugins/Cache/

Generated components are deliberately not auto-enabled.

Public package installation comes later.

Now the road toward Beta begins

Development has already moved beyond the Alpha tag.

Phase 8 — Evolve Insight is now in progress. The current roadmap shows the Insight storage projection and in-memory store foundation completed, with the SQLite diagnostic store next. Insight is intended to become EvolvePHP's local diagnostic system: collectors, safe diagnostic storage, retention and eventually a Telescope-style dashboard with Evolve-specific architecture and leak diagnostics.

Then comes Phase 9 — Evolve Observe and OpenTelemetry.

This takes a different role from Insight. Observe is intended for production observability: standard traces, metrics and structured logs, including context propagation across HTTP and background work.

Phase 10 — Infrastructure Contracts and Adapters moves EvolvePHP closer to practical application development by introducing replaceable contracts and initial adapters around databases, cache, sessions, queues, storage, locks, secrets and external clients.

A new Phase 10.5 — Views & Templating has also been added before reusable modules. The direction is a native PHP view engine with safe rendering, layouts, partials, shared data and module-aware view resolution, while keeping Twig or Blade optional rather than making either a framework-wide dependency.

One clarification to my earlier roadmap wording: Phase 11 is currently targeted at 2.0 Stable rather than Beta.

Phase 11 will prove the module architecture with real first-party reusable capabilities: Audit Log, Webhooks and API Keys.

So the progression is becoming much clearer:

Alpha
Core + HTTP + Modules + Doctor + Audit + Bridge
        ↓
Beta
Insight + Observe + Infrastructure + Views
        ↓
Stable direction
Reusable modules + further production hardening

A milestone, not the finish line

There is still a lot to build.

The Alpha does not yet provide the complete concrete production web runtime. Public package installation is not ready. Production deployment and several runtime integrations remain ahead.

But Alpha 1 matters because EvolvePHP has crossed an important line.

It is no longer only an architecture I am describing.

There is now code behind the execution model, module system, modernization workflow, Bridge, diagnostics and developer experience.

And from here, the work becomes increasingly visible.

EvolvePHP 2.0.0-alpha.1 is the first checkpoint.

Now we build toward Beta.

Microservices Are Not the Goal — Architectural Optionality Is

Microservices are often treated like the destination of a successful application.

Start with a monolith.

Grow.

Split into services.

Become “modern.”

I think that framing is backwards.

Microservices are not the goal.

The goal is to build a system that can change without forcing the business into a rewrite every time the architecture needs to evolve.

That is what I mean by architectural optionality.

A distributed system is not automatically a better system.

There are good reasons to use microservices:

• independent scaling,

• independent deployment,

• separate security boundaries,

• different team ownership,

• different runtime needs,

• different release cycles.

But distribution also introduces new problems:

network failures
timeouts
retries
idempotency
message delivery
service discovery
versioning
distributed tracing
data ownership
eventual consistency
operational complexity

Those costs may absolutely be worth it.

But they should be accepted because they solve a real problem, not because the system reached a certain size.

Scaling does not automatically mean microservices

A common assumption is:

More traffic
    ↓
Microservices

But traffic alone is not enough.

A well-designed monolith can handle a lot.

You can scale application instances horizontally.

You can introduce queues.

You can move files to object storage.

You can add caching.

You can optimize expensive operations.

You can improve database design.

None of those require turning every business capability into a separate service.

A better question is:

Which part of the system actually benefits from independent deployment?

That is much more useful.

Start with boundaries

Suppose an application has:

Customers
Orders
Billing
Reporting
Notifications

If all of those areas share everything freely, extracting Billing later will be painful.

But if they already have clear boundaries and explicit dependencies, you have options.

Billing can remain inside the monolith.

Or later it can move behind HTTP, a queue, RPC, or events.

That is the difference between:

“We need microservices.”

and:

“We can extract this capability if the evidence says we should.”

The modular monolith preserves choice

This is one reason I think the modular monolith is still underrated.

A good modular monolith gives you many of the architectural benefits people want from microservices:

• clear ownership,

• explicit dependencies,

• isolated business capabilities,

• testable boundaries,

• easier reasoning,

• replaceable implementations.

But you still deploy one application.

You still have local calls.

You still have one operational surface.

That keeps the system simpler while preserving the option to distribute later.

Extraction should happen because something changed

Imagine Billing suddenly needs to process ten times more work than the rest of the application.

Or a separate payments team takes ownership.

Or regulatory requirements demand stronger isolation.

Or Billing needs a deployment schedule that cannot be tied to the rest of the platform.

Now extraction has a reason.

Modular Monolith

Customers
Orders
Billing
Reporting
Notifications

        ↓

Customers
Orders       ──────> Billing Service
Reporting
Notifications

The architectural boundary already existed.

The deployment boundary changed.

That is healthier than starting with five services because you think the company might grow.

Optionality also applies to language choice

Suppose most of the system is PHP.

Later, one capability develops requirements that strongly favor Go or Rust.

Maybe it is CPU intensive.

Maybe it has a very different concurrency profile.

Maybe another ecosystem has better tooling for that workload.

If the architecture has good boundaries, you should be able to make that choice locally.

PHP Application
      |
      +---- Orders
      +---- Customers
      +---- Reporting
      |
      +---- High-throughput Worker → Go

That does not mean PHP failed.

It means the architecture allowed the team to choose the right tool without rewriting everything else.

Reversibility matters

One thing I increasingly value in architecture is reversibility.

How expensive is it to change your mind?

If choosing a framework, database, deployment model, or integration pattern creates a ten-year commitment, that decision deserves scrutiny.

Sometimes that commitment is necessary.

But where possible, I would rather preserve choices.

That does not mean abstracting everything.

Over-abstraction creates its own problems.

It means putting boundaries where the business already has meaningful boundaries and avoiding unnecessary coupling between them.

This influences EvolvePHP

A major design goal behind EvolvePHP is not:

“Make building microservices easy.”

It is closer to:

Build modular applications now, and make selective extraction possible later.

That is why explicit contracts, component boundaries, execution isolation, interoperability, and modernization matter so much.

A new EvolvePHP application should not need to begin as a distributed system.

The preferred path is:

Modular Monolith
       ↓
Observe actual pressure
       ↓
Identify the affected capability
       ↓
Extract only when justified

The same idea applies to existing systems.

Modernization should create options rather than simply replacing one form of lock-in with another.

The real goal

Microservices are useful.

So are monoliths.

So are queues, workers, serverless functions, and separately deployed services.

None of them should become an ideology.

The better question is:

Can our architecture support the deployment model we need when we actually need it?

That is architectural optionality.

And for long-lived software, I think that is more valuable than choosing the architecture that looks most advanced today.

Microservices are one possible destination.

The real goal is preserving the ability to choose.

Long-Running PHP with EvolvePHP: Designing for Safe Reuse

Long-running PHP is usually introduced as a performance story.

Boot the application once.

Keep the process alive.

Handle many requests or jobs.

Avoid repeating expensive initialization.

That can absolutely improve performance.

But while working on EvolvePHP 2, I have become more interested in a different problem:

How do you know the process is still safe to reuse?

That question changes how I think about persistent PHP.

Because keeping a process alive is easy.

Keeping it clean between executions is harder.

Traditional PHP gives you an automatic reset

With the classic request-per-process model, application state has a natural ending.

A request arrives.

PHP runs.

A response is produced.

The request ends.

Conceptually:

Start
  ↓
Boot
  ↓
Handle Request
  ↓
Response
  ↓
Process ends

Anything accidentally left in memory disappears with the process.

That is surprisingly useful.

Now imagine the process stays alive:

Boot
 ↓
Request A
 ↓
Request B
 ↓
Request C
 ↓
Request D
 ↓
...

Suddenly, state from Request A can potentially affect Request B.

The runtime has stopped giving us a clean slate automatically.

We have to create one ourselves.

The dangerous state is often ordinary state

Consider something simple:

final class TenantContext
{
    public static ?string $tenantId = null;
}

Request A sets:

tenantId = company-a

The request finishes.

Request B belongs to:

company-b

But if that static value was not reset correctly, we have a much more serious problem than a memory leak.

We have an isolation failure.

The same concern applies to:

• authenticated users,

• tenant context,

• database transactions,

• request caches,

• listeners,

• authorization state,

• telemetry context,

• temporary resources.

Long-running PHP turns lifecycle management into part of correctness.

EvolvePHP uses explicit execution boundaries

This is why EvolvePHP 2 does not model everything around an HTTP request.

The lower-level concept is an execution.

An execution might eventually represent:

HTTP request
Queue message
Scheduled job
CLI command
Worker task

The important part is that each unit of work gets a clear lifetime.

The model I am using is broadly:

Application
    │
    ├── Execution A
    │
    ├── Execution B
    │
    └── Execution C

The application may survive.

The execution must not.

That distinction is fundamental.

Service lifetimes need to match reality

EvolvePHP currently distinguishes three service lifetimes:

Application
Execution
Transient

Application services may survive across many executions.

Execution services belong to one unit of work.

Transient services are created when requested and are not cached.

This allows the container to reason about lifetime relationships instead of treating every dependency as equivalent.

For example:

Application-scoped service
        ↓
Execution-scoped CurrentUser

is dangerous.

The application service could capture a user belonging to one execution and retain it into another.

That relationship should not quietly succeed.

This is one of the areas where dependency injection becomes more than convenience.

It becomes a safety boundary.

Cleanup needs to be deterministic

At the end of an execution, EvolvePHP closes the execution scope.

Services that explicitly participate in reset can be cleaned up in a deterministic order.

Conceptually:

Execution starts
      ↓
Services created
      ↓
Operation runs
      ↓
Reset participants
      ↓
Scope closes

The important word here is explicitly.

I do not think a framework should pretend it can magically identify every piece of state that needs resetting.

Services that own reusable state need a clear cleanup contract.

And cleanup needs to happen even when the operation itself fails.

What if cleanup fails?

This was one of the questions that influenced the runtime architecture heavily.

Suppose the business operation succeeds:

Payment processed successfully

but during cleanup:

TenantContext reset fails

What is the result?

The payment still succeeded.

We should not rewrite history and pretend that it failed.

But can we safely reuse the PHP process?

Probably not.

That is why EvolvePHP separates two questions:

Did the operation succeed?

Is the process safe to reuse?

They are not the same question.

An execution outcome can preserve the original result or exception separately from cleanup failure.

Then the runtime can make an explicit reuse decision.

Conceptually:

Handler succeeds
Cleanup succeeds
        ↓
      REUSE

but:

Handler succeeds
Cleanup fails
        ↓
    QUARANTINE

The process is treated as uncertain.

The safe response is not:

“Hopefully the next request is fine.”

It is:

Do not give this process more work.

Quarantine is deliberately fail-closed

I like this model because it avoids pretending we know more than we do.

If cleanup failed, the framework may not be able to prove exactly what state remains.

So rather than attempting clever recovery inside Core, the result says that process reuse is unsafe.

A runtime adapter can later decide whether that means:

stop accepting work
finish current response
restart worker
replace process

That operational policy belongs to the runtime.

The framework's job is to expose the truth.

This also changes error handling

A long-running runtime can have four interesting outcomes:

Operation success + cleanup success
Operation failure + cleanup success
Operation success + cleanup failure
Operation failure + cleanup failure

The first two may still leave the process reusable.

The last two should not.

That is quite different from saying:

exception = bad
no exception = good

Runtime safety requires more information than that.

EvolvePHP is not claiming complete persistent-runtime support yet

There is an important limitation here.

EvolvePHP 2 already has the execution-scope, cleanup and reuse/quarantine foundations.

But the broader persistent-runtime work is still ahead.

Concrete integration with runtimes such as FrankenPHP and later RoadRunner, stronger persistent-worker validation, concurrency abstractions and production runtime adapters belong to later development.

So I would not currently describe EvolvePHP as a finished persistent PHP platform.

The architecture is being prepared for that future.

That distinction matters.

Long-running PHP is not just about speed

I think this is the biggest lesson.

Persistent execution can make PHP faster.

But once the process survives the request, performance becomes only one part of the engineering problem.

You also need to think about:

Lifetime
Isolation
Cleanup
Ownership
Failure
Observability
Reuse

Because a process that handles 10,000 requests quickly is not impressive if request 9,427 sees state belonging to request 9,426.

The real goal is not:

Keep PHP alive as long as possible.

It is:

Keep PHP alive only while we still have evidence that the process is safe to reuse.

That is the direction I want EvolvePHP's long-running runtime model to take.

Evolving PHP: The Language Is Changing, and So Is the Way We Build With It

 

For a long time, PHP had a very clear operating model.

A request comes in.

PHP starts.

The application runs.

A response goes out.

The process ends.

That model shaped a lot of how PHP applications were designed.

State could live in convenient places because the process was short-lived.

Global variables were less dangerous than they would be in a long-running process.

Memory leaks were often masked by process termination.

Cleanup was less visible because the runtime effectively cleaned everything up for you.

That model worked very well.

But PHP is evolving.

And the way we design PHP applications needs to evolve with it.

PHP is no longer only a request-per-process language

The traditional PHP-FPM model is still valid and useful.

But it is no longer the only serious way to run PHP.

Today, PHP can also run in long-lived workers, application servers, queue consumers, schedulers, event-driven processes, and persistent runtimes.

That changes something fundamental.

The application may now live for:

1 request
100 requests
10,000 requests
or hours of continuous work

That means old assumptions become more important.

What happens to request-specific state after the request finishes?

What happens to the current user?

The current tenant?

The database transaction?

Listeners?

Caches?

Telemetry context?

Temporary services?

A process that does not terminate forces us to answer questions that the traditional runtime often answered for us.

Performance is only part of the story

Persistent PHP is often discussed as a performance topic.

And performance does matter.

Booting the application once and reusing it can reduce repeated initialization work.

But I think the more interesting question is not:

“How much faster can PHP become?”

It is:

“What architectural assumptions change when the process survives?”

That is a much bigger question.

A persistent process can expose bugs that were previously hidden.

For example:

class UserContext
{
    public static ?int $currentUserId = null;
}

In a traditional short-lived request, this may appear harmless.

In a reused process, the next request may inherit stale state if cleanup is incomplete.

Now the problem is not performance.

It is isolation.

Dependency injection becomes more serious

Dependency injection is usually introduced as a way to improve testability and reduce coupling.

That is true.

But in long-running applications, it also becomes a lifetime problem.

Suppose an application-scoped service depends on a request-scoped service.

Conceptually:

Application Service
        ↓
Current User

If the application service lives for hours while the current user should live for one request, the lifetime relationship is wrong.

The container should not simply allow that because the types happen to match.

This is where service lifetimes start to matter much more:

Application
Execution
Transient

Application services can live across many executions.

Execution services belong to one request, job, or command.

Transient services are created when needed.

The relationship between them becomes part of application safety.

Cleanup becomes part of correctness

In short-lived PHP, process termination often acts as cleanup.

In a persistent runtime, cleanup needs to become explicit.

Imagine this flow:

Request starts
    ↓
User state created
    ↓
Transaction opened
    ↓
Telemetry context created
    ↓
Handler runs
    ↓
Cleanup begins

If cleanup succeeds, the process may be safe to reuse.

But what if cleanup fails?

That question does not get enough attention.

A framework should not simply assume:

“The request is over, continue.”

If the state of the process is uncertain, reusing that process can be dangerous.

Sometimes the correct answer is:

Do not reuse it.

That is a runtime safety decision, not just an error-handling decision.

Observability becomes more valuable too

Long-running systems are harder to understand when something goes wrong.

You may need to know:

• which execution created the state,

• which service failed to reset,

• whether cleanup completed,

• whether the process was reused,

• what happened before a failure,

• whether tenant or user context leaked.

Logs alone may not always be enough.

This is one reason I think observability needs to be designed into modern application architecture rather than added after problems appear.

Tracing, metrics, execution context, structured events, and failure evidence become more useful as runtime complexity increases.

PHP is also becoming more attractive for different workloads

The ecosystem is gradually making PHP viable for workloads that were traditionally pushed immediately toward other languages.

That does not mean PHP should replace everything.

Go, Rust, Java, and other languages remain excellent choices depending on the problem.

But PHP applications no longer need to assume:

“If this runs continuously, it must be rewritten in another language.”

Sometimes the correct answer may still be another language.

But it should be an architectural decision, not an automatic one.

If a PHP application can safely handle a workload with acceptable performance and operational behavior, there is value in keeping the system simpler.

Framework design needs to catch up

This is the part that interests me most.

A framework designed only around short-lived requests can still run in a persistent environment.

But that does not mean it was designed for one.

I think modern PHP frameworks increasingly need to think about:

• explicit service lifetimes,

• execution isolation,

• deterministic cleanup,

• stale-state prevention,

• runtime reuse decisions,

• observability boundaries,

• worker safety,

• concurrency assumptions,

• graceful failure.

These concerns should not be hidden inside runtime adapters.

They should influence the framework architecture itself.

This is influencing EvolvePHP

A lot of the EvolvePHP 2 architecture has been shaped by this idea.

The runtime model is not limited to HTTP requests.

An execution might be:

HTTP request
Queue message
Scheduled job
CLI command
Worker task

Each execution gets its own scope.

Execution-specific state should not silently become application-global state.

Cleanup is explicit.

Cleanup failures remain visible.

And if execution cleanup leaves the process in an uncertain condition, the runtime can decide that the process should not be reused.

My goal is not to make PHP look like Java or Go.

I acknowledge that PHP itself is changing.

And frameworks should evolve with it.

PHP’s future is not just faster PHP

When people talk about the future of PHP, the conversation often focuses on syntax, JIT, benchmarks, or framework performance.

Those things matter.

But I think the deeper evolution is architectural.

PHP is moving into environments where processes live longer, workloads are broader, infrastructure is more distributed, and operational expectations are higher.

That means application design has to become more deliberate.

The old request-per-process model hid a lot of complexity.

Persistent runtimes expose it.

And that is not necessarily a bad thing.

It gives us a chance to build systems with clearer boundaries, stronger isolation, better observability, and more predictable behavior.

PHP is evolving.

The interesting question now is whether our application architecture evolves with it.