Redis zie ik als een gerichte bouwsteen voor snelheid en coördinatie in backend-systemen. Het is waardevol wanneer je precies weet welk probleem je oplost: caching, tijdelijke status, distributie van werk of snelle toegang tot veelgebruikte data.

Bij ANWB werkte ik met Redis in een omgeving waar datastromen en verwerking onder druk stonden. Door de rol van Redis scherp af te bakenen, bleef het systeem beter uitlegbaar en konden we betrouwbaarheid en performance samen verbeteren.

Ik kies niet voor Redis omdat het snel is, maar omdat het past binnen een begrijpelijke architectuur. Zo blijft een optimalisatie ook op langere termijn beheersbaar.

Redis: snel, maar nooit vrijblijvend

Redis gebruik ik niet als standaardoplossing voor ieder performanceprobleem. Voor mij is het vooral waardevol wanneer je heel scherp weet welke verantwoordelijkheid het krijgt binnen een backend-systeem.

Dat kan caching zijn, tijdelijke state, rate limiting, locks of messaging. Maar zodra Redis tegelijk cache, database, queue en coördinatielaag wordt, ontstaat er meestal juist onduidelijkheid.

Redis binnen het Auto Informatie Platform

Bij ANWB werkte ik binnen het Auto Informatie Platform met Spring Kotlin, MongoDB en Redis. Het platform verwerkt voertuig- en mobiliteitsdata uit verschillende externe bronnen, met datastromen die niet altijd volledig of consistent binnenkomen.

Daar lag de uitdaging niet alleen in snelheid. We moesten vooral zorgen dat asynchrone processen beheersbaar bleven: wat is verwerkt, wat heeft opnieuw aandacht nodig en hoe voorkomen we dat tijdelijke technische keuzes langzaam onderdeel worden van de domeinlogica?

Redis hielp daar als gerichte bouwsteen. Niet als vervanging voor alle andere onderdelen van het systeem, maar als manier om snelle en tijdelijke verwerking goed te organiseren.

De vraag die ik eerst stel

Voordat ik Redis toevoeg, wil ik weten: welk probleem lossen we hiermee op dat niet al eenvoudiger in de bestaande architectuur kan worden opgelost?

Dat klinkt misschien als een eenvoudige vraag, maar juist daar zit de kwaliteit. Redis is snel en toegankelijk, waardoor het verleidelijk is om het voor steeds meer verantwoordelijkheden te gebruiken. Die snelheid mag geen vervanging worden voor een duidelijke keuze.

Voor mij moet iedere datastore en ieder platformonderdeel uitlegbaar blijven: welke data staat hier, hoelang blijft die bestaan, wie is eigenaar en wat gebeurt er als het onderdeel tijdelijk niet beschikbaar is?

Redis en asynchrone verwerking

In combinatie met Kotlin Coroutines kan Redis goed passen binnen processen die veel wachten op externe systemen, databases of andere services. Coroutines helpen om die concurrency leesbaar te houden; Redis kan op zijn beurt een rol spelen in de tijdelijke coördinatie van werk.

Dat betekent niet dat Redis de complexiteit wegneemt. Timeouts, retries, foutafhandeling, idempotency en observability blijven ontwerpvragen die je expliciet moet beantwoorden.

Voor mij zit de waarde daarom niet in zoveel mogelijk parallel uitvoeren. De waarde zit in processen overzichtelijk maken, zodat een team begrijpt wat er gebeurt wanneer de normale flow een keer niet normaal verloopt.

Waar ik voorzichtig mee ben

Een veelvoorkomend risico is dat cachegedrag stilzwijgend onderdeel wordt van de businesslogica. Dan lijkt het systeem snel zolang alles werkt, maar is niet meer duidelijk wat de bron van waarheid is zodra data veroudert of een cache wegvalt.

Daarom houd ik grenzen graag expliciet. Als data tijdelijk mag zijn, moet dat zichtbaar zijn. Als iets betrouwbaar afgeleverd moet worden, moet Redis ook met die verantwoordelijkheid worden ingericht en niet alleen als snelle tussenoplossing fungeren.

Veelgestelde vragen

Gebruik je Redis alleen voor caching?

Nee. Caching is een belangrijke toepassing, maar ik gebruik Redis ook voor tijdelijke state en asynchrone coördinatie. De juiste rol hangt af van het probleem en van de betrouwbaarheid die dat proces nodig heeft.

Kan Redis een primaire database vervangen?

Soms kan Redis een primaire rol krijgen, maar dat is voor mij geen lichte beslissing. Je moet dan heel bewust kiezen voor het datamodel, de persistentie, herstelbaarheid en de operationele verantwoordelijkheid die daarbij horen.

Wat is je belangrijkste principe bij Redis?

Snelheid is waardevol, maar duidelijkheid is duurzamer. Ik voeg Redis toe wanneer het een verantwoordelijkheid aantoonbaar eenvoudiger maakt, niet wanneer het alleen een technisch interessant extra onderdeel is.