Laravel Microservices
Architectuur voor wanneer een monoliet écht knelt. Eerlijk advies over wat te ontkoppelen, wat te laten, en hoe je het zonder big-bang doet.
Architectuur-audit besprekenEerst eerlijk: heb je dit echt nodig?
Microservices zijn populair, maar zelden de juiste keuze. Voor de meeste Laravel applicaties is een goed gestructureerde modulaire monoliet sneller, goedkoper en beter onderhoudbaar dan een verzameling services.
Wij adviseren microservices alleen als er een duidelijke business case is: teams die elkaar blokkeren, een component die wezenlijk andere schaal nodig heeft, of release-frequenties die niet samen passen. In alle andere gevallen: maak je monoliet beter.
Wanneer wél ontkoppelen?
- Je hebt 3+ teams die in dezelfde codebase werken en elkaar in de weg lopen
- Eén component heeft fundamenteel andere schaal nodig (10x meer traffic of resources)
- Eén component heeft een ander release-tempo (mobile API dagelijks, rest maandelijks)
- Je hebt regulatory/security eisen die isolatie vereisen (bijv. payments apart)
- Je monoliet is technically unmaintainable en strangler-pattern is realistischer dan rewrite
- Je wilt taal-diversiteit (Laravel + Go + Python) waar het écht waarde toevoegt
Architectuur-patronen die we toepassen
Niet één patroon is "het juiste". We kiezen wat past bij jouw realiteit.
Modulaire Monoliet
Eén deployment, duidelijk gescheiden modules (Domain Driven Design). Voor 80% van projecten de juiste keuze.
Service Extraction
Eén component eruit halen die andere schaal of release-cadans nodig heeft. Bijv. API extern, image processing apart.
Event-Driven Architecture
Services communiceren via events op een queue/bus. Losse koppeling, betere fault-tolerance.
BFF (Backend for Frontend)
Aparte Laravel laag per frontend (web, mobile, B2B portal). Eigen schema, gemeenschappelijke services.
API Gateway
Eén entrypoint voor alle externe traffic. Authentication, rate limiting, routing — gecentraliseerd.
Strangler Fig
Geleidelijke migratie van legacy naar nieuwe architectuur. Nieuwe routes naast oude, traffic langzaam verleggen.
Tech stack voor distributed Laravel
Bewezen componenten. Geen experimenten in productie.
Laravel Octane
Swoole/RoadRunner voor 3-5x throughput
Laravel Horizon
Queue monitoring en management
Redis
Cache, queue, session store
RabbitMQ
Event streaming en pub/sub
OpenTelemetry
Distributed tracing standaard
Docker / Kubernetes
Containerization en orchestratie
Onze volgorde
- 1.Architectuur-audit van huidige monoliet
- 2.Modulariseren binnen monoliet (DDD modules)
- 3.Observability vóór splitsen opzetten
- 4.Eerste service extraheren via strangler
- 5.Patterns vaststellen en herhalen
- 6.Evalueren: stoppen als de pijn weg is
Waar je rekening mee moet houden
De échte kosten van distributed systemen.
Distributed transactions
Geen ACID over services — saga's en compensaties
Data consistency
Eventual consistency vs strong consistency keuze
Testing complexity
Contract tests, integration tests, end-to-end
Observability
Vóór splitsen al inrichten, niet erna
Operationele kosten
Meer infra, meer monitoring, meer engineering
Team Conway's Law
Architectuur weerspiegelt teamstructuur — pas in lijn
Veelgestelde vragen
Heeft mijn project microservices nodig?
Bijna nooit zo zwart-wit. Voor de meeste Laravel applicaties is een goed gestructureerde monoliet (Domain Driven Design + modules) beter dan een microservices-architectuur. Microservices brengen complexiteit: networking, distributed transactions, deployment, observability. We adviseren ze pas als de monoliet écht knelt — bij teamgrootte, schaal of release-frequentie.
Wanneer is een monoliet ontkoppelen wél verstandig?
Als één component andere snelheid van releases nodig heeft (bijv. mobile-API), als één component opvallend zwaarder is qua resources (bijv. PDF-rendering, image processing), of als je verschillende teams hebt die elkaar in de weg lopen in één codebase. In die gevallen kan een service extraheren waardevol zijn — niet meteen "alles".
Hoe communiceren Laravel microservices?
Voor synchroon: HTTP/REST of gRPC. Voor asynchroon: queues (Redis, SQS, RabbitMQ) of event streaming (Kafka). Wij gebruiken bij voorkeur events + queues — losser gekoppeld, beter te schalen, makkelijker te retrying.
Wat kost een microservices traject?
We starten met een architectuur-audit (€3.000-€5.000). Daarna een gefaseerd extract-plan. Een eerste service uit een monoliet halen: €15.000-€40.000. Daarna meestal goedkoper per service als de patterns staan. Eerlijk: dit is duurder dan het lijkt — alleen doen als de business case er is.
Strangler pattern of big-bang rewrite?
Bijna altijd strangler. Nieuwe code naast de monoliet draaien, geleidelijk verkeer ernaartoe verschuiven, oude code laten "afsterven". Big-bang rewrites mislukken zo vaak dat we ze afraden tenzij de huidige codebase echt onhanteerbaar is.
Hoe zit het met observability bij microservices?
Cruciaal. Distributed tracing (OpenTelemetry, Jaeger), centralized logging (ELK, Loki), metrics (Prometheus, Grafana). Zonder dit ben je blind bij failures. We zetten observability standaard op vóór we de eerste service splitsen.
Architectuur-audit eerst, microservices misschien
We doen een architectuur-audit en geven een eerlijk advies. Soms is de conclusie: blijf bij je monoliet en maak hem beter. Soms: tijd om te ontkoppelen. We zeggen het.
Architectuur-audit plannen