From Laravel Monolith to Swoole-Powered Microservice with Laravel Microservice Core

The Inflection Point: When Growth Outpaces Architecture

Many PHP or Laravel applications start as a monolith—ideal for a small business or an initial product launch. The problem arises when that business grows faster than anticipated. The monolith begins to accumulate too much logic, integrations, and disparate use cases. Suddenly, scaling becomes difficult, and making even the slightest change becomes a real challenge. At that point, the idea of "moving to microservices" inevitably comes up as a way to regain velocity and scale horizontally at a reasonable cost.

However, when the starting point is a Laravel monolith, the technical conversation inevitably lands on the same question: if we're already going to make the effort to migrate, isn't this the perfect time to rewrite everything in a "modern" language like Go, Rust, or TypeScript?

In many cases, however, the reality is quite different. The platform has accumulated years of production-proven business logic, complex validations, fiscal rules, and critical integrations that were difficult to align and stabilize. While rewriting everything in a new language is technically appealing, in practice, it's not just costly but also incredibly risky:

• It means re-implementing features that are already working perfectly.

• It increases the risk of introducing new bugs into processes the business considers "solved."

• It extends the development timeline significantly before any tangible benefits are seen in production.

The Proposal: A Progressive Migration Approach

That's why this post proposes a more pragmatic approach: leverage the existing PHP/Laravel logic and progressively isolate it into new microservices that also use Laravel. The key is to apply this strategy selectively, choosing only those services where we can afford the performance trade-offs this entails. This way, we gain scalability and isolation without the cost and risk of an immediate, total rewrite.

That said, this path has its own downsides, and it's important to be transparent about them. A Laravel microservice (even an optimized one) typically involves:

• Higher resource consumption: It must load the entire framework into memory, consuming more than a Go or Rust binary.

• Heavier Docker images: The final image size is often significantly larger.

• Longer build times: CI/CD pipelines take longer to build and test the service.

Slower initial startup (Pod Startup): We're not talking about per-request latency here, but the time it takes for a Kubernetes pod to become "Ready". A Go binary starts almost instantly, but a Laravel/Swoole container needs to load the interpreter, extensions, and the entire framework into memory before it can accept traffic.

So, if this path doesn't win in the "absolute lightness" of a Go binary, what are we actually gaining? We win on three key fronts: time, continuity, and a huge leap in performance.

• Time, because we don't have to rewrite all the business logic; we can extract it from the monolith in a controlled way.

• Continuity, because the team keeps working with a stack they already know (PHP, Laravel), while taking steps toward a more modular and scalable architecture.

• A huge leap in performance: By using Swoole, we get high-level performance, completely eliminating the boot-time latency of PHP-FPM. It's not the "number 1" in raw speed (like Go or Rust), but it's a radical improvement and more than enough for the vast majority of services.

Content and Objectives of this Series

In this series of articles, I want to share a concrete way to make this transition using Laravel Microservice Core as the base for the microservices and Swoole as the high-performance runtime, all packaged in Kubernetes-ready containers.

In this first part, I'll show you "How to migrate a part of the monolith to a Laravel microservice, without dying in the attempt," in a brief but realistic way, leveraging the library's utilities to avoid reinventing every technical piece from scratch.

Later on, we'll get into topics like remote models between microservices, how to coordinate a Laravel frontend that coexists with independent services, and practical patterns for continuing to "strangle" the monolith without breaking the project's day-to-day operations.

Understanding the Stack: Laravel Microservice Core and Swoole

Author

Sebastián Richiardi

@kroder