Sharing knowledge: a sustainable asset

In the field of development, the value of expertise is measured by its ability to be transmitted. We invite you to see or review the speech of Jonathan Van Belle, one of our Belgian Linkers, captured during the PHP 2025 Forum.

To mark the 30th anniversary of technology, Jonathan took the stage at'AFUP to address a subject that remains at the heart of the concerns of backend teams: the reliability of asynchronous processes.

A problem at the heart of performance

In his talk “Jobs, queues & events: anatomy of common mistakes and possible solutions”, Jonathan dissects the invisible but critical mechanisms of modern web applications.

If you're working on high-traffic PHP environments, you may be familiar with the questions raised in this video:

• How to react when workers stop without warning?
• What are the strategies for unblocking queues?
• How to effectively diagnose the origin of a failure?

Watch the intervention

Whether you missed the event or are looking for ways to optimize your current projects, we invite you to watch the replay of this technical intervention:

To go further: 5 questions to Jonathan

On the sidelines of his conference, we asked Jonathan a few questions to deepen his vision of the business and PHP architectures.

1. PHP is celebrating its 30th anniversary and has reached an impressive maturity. However, we note that memory and resource management remain a frequent pain point on projects. In your opinion, is it a training problem or a complexity inherent in modern architectures?

In a modern system, with a certain level of complexity, regardless of the technology used, optimization of memory and other types of resources always comes up in the end.

In PHP in particular, memory is not always easy to understand, in particular because of the data structure that is hidden by the language itself, not to mention some common libraries that do not facilitate the task at all.

In reality, the concern for optimizing resources has always existed, whether at the time of Apollo or today. The difference is that currently, the management of work is oriented towards more functionalities, as quickly as possible, where previously resource constraints were a critical barrier.

2. You place a lot of emphasis on the use of generators (yield) and streams. Why are these native mechanisms still too often underestimated compared to adding raw RAM, and what is their real impact on scalability?

These two mechanisms are what we call coroutines. These are mechanisms for starting, suspending and resuming certain activities. Unfortunately, their use cases are often unknown and concrete native implementations derive so much from this principle that streams and yield have not yet really been integrated by developers.

At their core, these coroutines are mechanisms that were not developed for cloud-like scalability, but rather for local use, by distributing work across the many cores of a CPU or across several processes. In order to distribute but also to optimize certain aspects, such as memory. As is often the case in computer science, we are rediscovering the same mechanisms that we are regularly modernizing.

When we talk about cloud-type scalability, this will therefore play a number of roles. It is above all a question of architectural choice, depending on where you want to place the cursor, the team you have, the technologies used, etc. This plays a huge role.

The reason why I insisted on these mechanisms is that when using workers, managing them well makes it easier to scale, whether horizontal or vertical. This allows for better distribution of resources. Adding raw RAM can certainly solve some problems, but you can't add more to it forever. Moreover, in view of current events, the management of this cost is likely to become critical.

3. Protecting a worker is crucial, but you should not make the system “mute” in the face of errors. What is your advice for implementing a Circuit Breaker that protects the infrastructure while reporting relevant alerts to third-party APIs?

My advice is to remain pragmatic and to make do with the technology at your disposal. The Circuit Breaker is a simple pattern: you just have to keep in mind what you want to protect and how the system reacts.

The implementation can range from a simple flag in a file or a value in the database, to very complex dedicated systems. However, like any mechanism that adds complexity, the pros and cons must be weighed.

I tend to keep things simple and adapt the solution case by case:

• For an API called intensely: I let the monitoring manage the case (probes, error logs, metrics...). If possible, the calling process won't even be started anymore.
• For an API called from time to time: I monitor the response and record the error cases to put a flag (file, key-value system with timeout,...)

Those are two examples, but that gives you an idea. It all depends on the objective: to avoid consuming resources unnecessarily, to prevent cascading errors, or to protect the partner API.

4. We often talk about code, less about the operating system. In what way has controlling POSIX signals become an essential skill to ensure uninterrupted deployments (Graceful Shutdown), especially in containerized environments?

When you ask a container to stop, it necessarily ends up stopping. But let's take the case of Docker: by default, there is a timeout of 10 seconds before the forced shutdown.

Imagine a scenario with 30 containers linked to each other, waiting for the previous one to stop: if all of them reach this timeout, we can theoretically reach 300 seconds of waiting (5 minutes)!

By properly managing stop signals, the order is transmitted directly to the main container process. Stopping is often much faster than timeout. Instead of waiting 5 minutes, the system may shut down in 30 seconds, making recovery or deployments much easier.

In the end, this control is essential: it not only saves time, but also allows you to better understand the system in order to optimize monitoring and debugging.

5. You mentioned the integration of OpenTelemetry, which still seems to lack maturity in the current PHP ecosystem. What changes do you expect for this technology to become the reliable observability standard that everyone hopes for?

On the side of the PHP language itself, there is nothing to expect in particular. Rather, it is up to the ecosystem to accelerate adoption: popular frameworks and libraries must integrate OpenTelemetry natively. We are also sorely lacking examples of clean and concrete implementations.

The real sticking point comes from OpenTelemetry: documentation is a major barrier. It contains a lot of very low-level information, but it lacks an overall vision of how it works.

For a developer looking to achieve a clean integration, by properly managing resources, it's not clear what to do. This is a regrettable obstacle to the adoption of this promising technology.

Technical culture within the Group

Within the IT Link Group, we make it a point of honor to ensure that the expertise of our employees does not remain isolated. By relaying this conference on our site, we want to promote Jonathan's approach: that of an engineer who takes the time to analyze, structure his knowledge and transmit it to the community.

It is this state of mind of continuous progress and sharing that drives our teams on a daily basis!

Congratulations again to Jonathan!

‍