MongoDB

MongoDB gebruik ik vooral wanneer data niet vanzelfsprekend in een traditioneel relationeel model past. Voor mij zit de kracht niet alleen in het feit dat MongoDB een document database is, maar vooral in de vrijheid om data te modelleren rondom het domein en de manier waarop een applicatie die data daadwerkelijk gebruikt.

In de afgelopen jaren heb ik MongoDB binnen verschillende backend-omgevingen toegepast, onder andere bij ANWB, Sogeti en Marvia. Daardoor heb ik MongoDB zowel gebruikt binnen grotere platformen als binnen microservice-architecturen waarin schaalbaarheid, data-integriteit en onderhoudbaarheid centraal staan.

Data modelleren vanuit het domein

Bij MongoDB begin ik niet vanuit collections of documenten, maar vanuit de vraag: welke data heeft deze service nodig om zelfstandig zijn verantwoordelijkheid uit te voeren?

Dat betekent bewust nadenken over document boundaries, embedding versus references, ownership van data, indexes, query-patronen, duplicatie en consistentie tussen services.

MongoDB maakt het eenvoudig om flexibel te modelleren. Die flexibiliteit vraagt tegelijkertijd om discipline. Zonder duidelijke grenzen verschuif je complexiteit namelijk alleen maar van je database naar je applicatie.

Mijn voorkeur ligt daarom bij modellen die bewust eenvoudig blijven en aansluiten op het domein.

MongoDB binnen microservices

Binnen een microservice-architectuur zie ik MongoDB vooral als datastore van een specifieke bounded context. Een service is eigenaar van zijn eigen data en andere services communiceren daarmee via duidelijke API's of events.

Hierdoor voorkom je dat verschillende services rechtstreeks afhankelijk worden van dezelfde database.

Bij Sogeti heb ik MongoDB bijvoorbeeld gebruikt tijdens onderzoek naar Immediate Consistency en Eventual Consistency binnen Domain Driven Design. Daarbij zijn verschillende prototypes gebouwd met Java, Quarkus, MongoDB, Kafka en Docker om te onderzoeken wat consistency-keuzes betekenen voor een gedistribueerde architectuur.

MongoDB wordt daarmee niet alleen een opslagmechanisme, maar onderdeel van een bredere architecturale keuze.

MongoDB bij ANWB: soms is uitfaseren de beste keuze

Bij ANWB kwam ik uiteindelijk tot een andere conclusie: MongoDB was technisch prima, maar binnen onze architectuur niet meer noodzakelijk.

Binnen het Car Platform werkten we met Spring Kotlin, MongoDB en Redis en verwerkten we veel data vanuit externe bronnen. Naarmate de architectuur verder evolueerde, heb ik opnieuw gekeken naar de verantwoordelijkheid van MongoDB binnen het platform.

De belangrijkste vraag was simpel: welk probleem lost deze database op dat we niet al op een eenvoudigere manier oplossen?

Mijn conclusie was dat MongoDB onvoldoende toegevoegde waarde meer had om de operationele kosten te rechtvaardigen. Tegelijkertijd betaalden we iedere maand een aanzienlijk bedrag voor de infrastructuur eromheen.

Daarom heb ik de keuze gemaakt om MongoDB uit te faseren.

Voor mij is dat net zo goed software engineering als het introduceren van nieuwe technologie. Misschien zelfs belangrijker. Een technologie behouden omdat deze er eenmaal staat, is geen architecturale strategie.

Door MongoDB weg te halen konden we de technische architectuur eenvoudiger maken én structurele kosten reduceren. Het vrijgekomen budget kon vervolgens op plekken worden ingezet waar het daadwerkelijk meer waarde opleverde.

Dat is voor mij een belangrijk onderdeel van duurzame software engineering: niet alleen kijken naar performance en schaalbaarheid, maar ook naar operationele kosten, onderhoudslast en daadwerkelijke businesswaarde.

De beste technologie is soms de technologie die je bewust niet meer gebruikt.

MongoDB en Eventual Consistency

MongoDB komt voor mij vaak samen met event-driven architecturen.

Wanneer iedere microservice eigenaar is van zijn eigen datastore, ontstaat vanzelf de vraag hoe data tussen services consistent blijft. Een distributed transaction over meerdere databases probeer ik daarbij zoveel mogelijk te vermijden.

Mijn voorkeur ligt dan bij expliciete processen:

Event → lokale verwerking → lokale persistentie → nieuw event

Wanneer meerdere stappen samen één bedrijfsproces vormen, kunnen patronen zoals Saga helpen om die verantwoordelijkheid expliciet te maken.

Tijdens mijn werk en onderzoek heb ik MongoDB onder andere gecombineerd met Kafka om precies dit soort eventual-consistency scenario's te onderzoeken en implementeren.

Performance begint bij het datamodel

MongoDB is snel, maar een verkeerde datastructuur blijft een verkeerde datastructuur.

Ik kijk daarom vroeg naar welke queries het systeem daadwerkelijk uitvoert, welke velden geïndexeerd moeten worden, hoeveel documenten een query moet doorzoeken, hoe groot documenten kunnen worden en hoe vaak data wordt gelezen tegenover geschreven.

Een index toevoegen aan iedere query is geen performance-strategie. Het model moet aansluiten op het gebruik van de data.

Dat is voor mij ook een belangrijk verschil met relationele databases: bij MongoDB ontwerp je vaak sterker vanuit access patterns.

Wanneer kies ik MongoDB?

MongoDB is voor mij interessant wanneer data van nature documentgericht is, objecten verschillende of evoluerende structuren hebben, een microservice zelfstandig eigenaar moet zijn van zijn datastore of reads goed rondom een document kunnen worden georganiseerd.

Maar de technische fit alleen is niet voldoende.

Ik kijk ook naar:

• operationele kosten;

• beheerlast;

• kennis binnen het team;

• bestaande infrastructuur;

• schaalbaarheid;

• complexiteit die een extra datastore introduceert;

• de daadwerkelijke businesswaarde.

Ik kies MongoDB dus niet puur omdat een systeem veel data bevat of omdat het NoSQL is.

En net zo belangrijk: als die argumenten later veranderen, moet je bereid zijn om je eerdere keuze opnieuw ter discussie te stellen.

Veelgestelde vragen

Waarom MongoDB en niet PostgreSQL?

Dat hangt volledig af van het domein. Bij documentgerichte data geeft MongoDB vaak een natuurlijker model en meer flexibiliteit. Wanneer relaties, joins en transactionele integriteit dominant zijn, zou ik eerder richting PostgreSQL kijken.

Is schema-less niet gevaarlijk?

MongoDB is flexibel, maar dat betekent niet dat je zonder structuur moet werken. Juist binnen grotere systemen probeer ik duidelijke domeinmodellen en validatie af te dwingen. Flexibiliteit moet bewust gebruikt worden.

Gebruik je MongoDB ook met Eventual Consistency?

Ja. Vooral binnen microservices vind ik dat een logische combinatie. Iedere service beheert zijn eigen state en synchroniseert veranderingen via events, bijvoorbeeld met Kafka.

Waarom heb je MongoDB bij ANWB uitgefaseerd?

Omdat een technologie zichzelf moet blijven rechtvaardigen. In onze situatie leverde MongoDB uiteindelijk onvoldoende unieke waarde, terwijl er wel aanzienlijke maandelijkse kosten tegenover stonden. Door het uit te faseren hebben we de architectuur eenvoudiger gemaakt en budget vrijgespeeld voor onderdelen die meer waarde toevoegden.

Wanneer zou je MongoDB juist niet gebruiken?

Wanneer het domein sterk relationeel is, wanneer een andere datastore dezelfde verantwoordelijkheid eenvoudiger kan dragen, of wanneer de operationele kosten en complexiteit niet opwegen tegen de daadwerkelijke voordelen. MongoDB moet een bewuste keuze zijn — en dat geldt ook voor het besluit om ermee te stoppen.