We hebben Modular twee keer opgeknipt in losse services en het twee keer teruggedraaid. Dit is wat we gemeten hebben, en waarom de kern voorlopig één deployable blijft.
01 De meting
De eerste splitsing zette content, rechten en routing in drie services. Een gemiddelde paginarender ging van 41 milliseconden naar 128. Dat kwam niet door de services zelf, maar door het aantal keer dat ze elkaar nodig hadden binnen één verzoek. We telden gemiddeld negen interne calls per render, waarvan zeven naar de rechtenservice.
Caching hielp, tot de eerste keer dat iemand een rol wijzigde en de cache twintig minuten lang de oude rechten bleef teruggeven. Toen kwam de tweede les: rechten zijn geen data die je mag verouderen.
02 De grens die wel werkte
Eén splitsing hield wel stand. Alles wat buiten het verzoek om mag draaien is nu een aparte worker: exports, beeldverwerking, webhooks, e-mail. Die dingen delen geen state met de render en ze mogen falen zonder dat een bezoeker het merkt.
De regel die we daaruit haalden staat sinds april in onze RFC-tekst. Een service knippen mag als de grens langs tijd loopt, niet als hij langs een domeinbegrip loopt.
03 Wat het kostte
Twee mensen, elf weken, verspreid over anderhalf jaar. Dat is duur voor een experiment dat je terugdraait.
Een teruggedraaid experiment is geen verspilling zolang je opschrijft wat je gemeten hebt.
04 Hoe het nu staat
Modular draait als één applicatie met vijf workers ernaast. Een gemiddelde render zit op 38 milliseconden. De codebase is met 6 procent gegroeid ten opzichte van de gesplitste versie, en het aantal plekken waar je moet kijken bij een fout is van vier naar één gegaan.
Als het verkeer verdertienvoudigt kijken we opnieuw. Tot die tijd is dit de goedkoopste versie die werkt.