Microservices zijn vaak de verkeerde keuze om mee te beginnen. Een veel voorkomende regel is "monolith first": begin met een goed gestructureerde monolith en extract services alleen wanneer je een concrete reden hebt.
Waarom het belangrijk is
✗ Small team — more services than people to run them
✗ Early-stage product — domain boundaries still shifting
✗ No CI/CD, monitoring, or tracing in place
✗ Low traffic — no real scaling pressure
✗ Simple domain — splitting adds cost, not value
De kosten van voortijdig splitsen
Een in-process methodaanroep naar een netwerkaanroep verplaatsen voegt latentie, foutscenario's, serialisatie en een deployment unit toe. Als de grenzen verkeerd zijn, betaal je dat allemaal moet je nog steeds refactoren over services heen.
