Life Beyond Microservices: Modular Monoliths in Laravel
summary
Argues that for many Laravel projects a modular monolith outperforms microservices by avoiding network latency, version drift and orchestration overhead. Recommends concrete practices: use Laravel Service Providers as module entry points, prefix database table names per module, develop modules as local Composer packages with autodiscovery inside a monorepo to keep commits and versions consistent, and shows measured latency differences (~10 ns in‑process vs 20–200 ms over HTTP) while reporting that modules and event-driven interactions work reliably in practice.
AI-written summary · about
chapters (17)
- 0:00Beyond microservices
- 1:07Legacy monolith problems
- 2:31Microservices as solution
- 3:30Hidden microservice complexity
- 10:45Microservices not panacea
- 11:07Modular monoliths in Laravel
- 14:02Service providers for modules
- 16:14Database suffixes in modules
- 17:40Composer autodiscovery
- 20:31Monorepo for modules
- 24:52From spaghetti to services
- 25:37When microservices fit
- 31:10Module dependencies
- 32:33Logic separation
- 34:01Microservices human factor
- 35:50Scaling monoliths
- 36:30Q&A
related talks
34mMateus Guimarães :: Unveiling the Modular Monolith
47m"Modulitiche" Applications
28mManaging a team building a modular monolith in Laravel
40mFrameworkless – The New Black?
38mModular-services in a Nodejs Monolith
23mMicroservices within a Monolith
40mEngineering Complex Applications with Laravel 4
43mGo micro with Microservices