How We Turned PHP into a High‑Performance Microservice with Phalcon & Swoole

Introduction

This four‑year journey recounts how we rewrote a high‑load microservice using Phalcon and Swoole, explaining why we chose the migration, the obstacles we faced, and how we overcame them. The story is aimed at PHP enthusiasts and anyone who thinks PHP is only for small projects.

Project History and Background

The original codebase was a legacy PHP 5.6 monolith later upgraded to PHP 7.0, running in a private data center on dozens of Proxmox VMs with 50‑100 CPUs and hundreds of gigabytes of RAM. Despite the abundant hardware, the classic Nginx + PHP‑FPM stack could not meet the required performance and scalability.

Planning and Design

Initially we considered a full rewrite in Go because of its concurrency model, but the code contained thousands of hard‑coded business rules, making a direct migration infeasible. We needed a solution that allowed incremental, low‑risk steps while gradually improving performance.

Phalcon combined with Swoole emerged as a promising path, even though Phalcon was not originally designed to work with Swoole and no existing integration library existed. We therefore built a bridge that forwards Swoole Request and Response objects into Phalcon’s MVC pipeline and returns the output to Swoole.

Implementation

The biggest technical challenge was memory management. Because the service starts once and keeps everything in memory, we had to prevent leaks and ensure stable long‑running operation.

Our service validates incoming data and forwards it asynchronously to Kafka. We introduced an internal hot cache using Swoole\Table that is refreshed every hour via Swoole\Tick from data stored in S3, minimizing latency for data retrieval.

Challenges and Solutions

We spent considerable time identifying, debugging, and fixing memory leaks inside Phalcon itself, which was essential for long‑term stability and high performance.

The incremental refactoring approach let us keep business logic in PHP while leveraging Swoole’s asynchronous capabilities, achieving a balance between continuity and performance improvement.

Choosing a reliable Kafka client that works with AWS MSK (managed Kafka) and establishing a single persistent connection at server start were critical. After extending the Swoole Kafka client to support AWS MSK authentication, we achieved a stable, leak‑free system.

Results and Outcomes

The migration delivered several concrete benefits:

Stability and Performance

Memory‑leak elimination and a long‑running architecture resulted in a highly stable system that maintains performance under heavy load.

Efficient Memory Usage

Strict debugging and optimization removed previous memory leaks, allowing the service to run continuously without degradation.

Improved Response Time

The combination of Phalcon’s efficiency and Swoole’s async model significantly reduced average response times, even under high traffic.

Enhanced Scalability

Swoole’s concurrent connection handling and resource management let us handle larger request volumes on the same hardware.

Simplified Maintenance

Keeping business logic in PHP and using Phalcon’s MVC framework created a modular codebase that is easier to extend and modify.

Integration with AWS MSK

Implementing missing features in the Swoole Kafka client, such as AWS MSK authentication, provided a reliable, scalable messaging solution.

Deployment Convenience

We containerized the service with a straightforward Dockerfile:

FROM php:8.1-cli

COPY . /srv
WORKDIR /srv

RUN pecl install phalcon swoole

EXPOSE 9501

ENTRYPOINT ["php", "/srv/server.php"]

Conclusion

Rewriting our high‑load microservice with Phalcon and Swoole was a transformative process that achieved stability, performance, and scalability goals, demonstrating that with the right tools and methodology, PHP can power high‑performance, enterprise‑grade workloads.