Redis — in-memory caching voor websites en webshops
Redis is de snelheidslaag achter de websites, webshops en marktplaatsen die op 4buildsite ontstaan: het houdt precies die gegevens in het werkgeheugen (RAM) die direct geleverd moeten worden — gecachete pagina's, sessies, winkelwagens, limieten op het aantal aanvragen — en antwoordt in minder dan een milliseconde. De bron van waarheid blijft PostgreSQL; Redis beschermt die bij veel verkeer. Het is inbegrepen en wordt door het platform beheerd, zonder dat jij iets hoeft in te stellen.
Wat Redis is en waarom het zo snel is
Redis (REmote DIctionary Server) is een opensource in-memory database: hij houdt de gegevens in RAM in plaats van op schijf en antwoordt daardoor in minder dan een milliseconde. Op 4buildsite gebruiken we hem als versnellingslaag vóór PostgreSQL — voor alles wat meteen geleverd moet worden: pagina's, sessies, winkelwagens en limieten op het aantal aanvragen.
Anders dan een schijf is RAM ordes van grootte sneller, en Redis voegt daar native datastructuren aan toe (string, hash, lijst, set, sorted set, stream) die complexe bewerkingen rechtstreeks in het geheugen mogelijk maken, zonder omweg via de hoofddatabase. De verwerking van commando's is single-threaded, dus het gedrag is voorspelbaar en vrij van race conditions.
- Typische latentie onder 1 ms en meer dan 100.000 bewerkingen per seconde op één enkele node
- Native structuren: hashes voor sessies, sorted sets voor ranglijsten en rate limiting, streams voor queues
- Single-threaded bij commando's → voorspelbaar gedrag, zonder ingewikkelde blokkades
Caching: jouw pagina's en gegevens uit het geheugen
De strategie is cache-aside: de eerste aanvraag leest uit PostgreSQL en zet het resultaat met een TTL (levensduur) in Redis; de volgende aanvragen halen het rechtstreeks uit het geheugen. Wanneer je een pagina bewerkt, wordt de sleutel uitdrukkelijk verwijderd — we leveren nooit verouderde gegevens via een blinde TTL.
Voor een bedrijfswebsite of een webshop betekent dat dat productlijsten, menu's, populaire pagina's en inhoudsfragmenten uit het geheugen geleverd kunnen worden, zonder de database te overbelasten. Op piekmomenten (een campagne, Black Friday) vangt Redis de herhaalde aanvragen op.
- Cache-aside met uitdrukkelijke invalidatie — geen verouderde gegevens
- Slaat paginafragmenten en queryresultaten op, niet alleen hele pagina's
- Beschermt PostgreSQL bij verkeerspieken
Sessies, winkelwagen en bescherming tegen misbruik
Gebruikerssessies en refresh-tokens staan in Redis: authenticatie, automatisch verlopen via TTL en intrekking op alle apparaten zodra iemand uitlogt of het wachtwoord wijzigt.
De winkelwagen van de webshops die op 4buildsite gebouwd zijn, staat voor niet-ingelogde bezoekers in Redis — met een vervaltijd en zonder de hoofddatabase op te blazen. Ook de rate limiting op contactformulieren en bij het inloggen wordt door Redis uitgevoerd, met behulp van sorted sets, om spam en brute-force-pogingen te stoppen voordat ze de database bereiken.
- Session store met automatisch verlopen en selectieve intrekking van de tokens
- Blijvende winkelwagen met TTL voor anonieme bezoekers
- Rate limiting en bescherming tegen misbruik bij formulieren en inloggen
Realtime en queues op de achtergrond
Redis pub/sub en streams drijven de realtime-updates aan: voorraad die live daalt, een melding in de applicatie, een bestelstatus die verandert — allemaal zonder dat de bezoeker de pagina hoeft te herladen en zonder herhaald pollen dat de server vermoeit.
Zware taken (het verwerken van een afbeelding, het genereren van een export, een synchronisatie) belanden in een Redis-queue en worden door workers op de achtergrond uitgevoerd, zodat de bezoeker niet op de verwerking hoeft te wachten. Een gedistribueerd slotmechanisme zorgt ervoor dat een kritieke bewerking niet twee keer draait.
- Pub/sub en streams voor live gebeurtenissen (voorraad, bestellingen, meldingen)
- Job queues voor zware verwerkingen die asynchroon draaien
- Gedistribueerde locking voor bewerkingen die niet twee keer mogen draaien
Voordelen en beperkingen
Voordelen
- Antwoord in minder dan 1 ms per sleutel, uit het geheugen
- Verlaagt de belasting op PostgreSQL bij veel verkeer
- Native structuren voor sessies, winkelwagen, rate limiting en ranglijsten
- Pub/sub en streams voor realtimefuncties, zonder pollen
- Job queues voor zware verwerkingen, zonder de bezoekers op te houden
- Inbegrepen en beheerd door het platform — nul configuratie voor jou
Beperkingen
- De gegevens staan in RAM, dat duurder is dan schijfopslag → niets voor enorme hoeveelheden zelden gebruikte gegevens
- Het is een cache oftewel een hulplaag, niet de bron van waarheid — de blijvende gegevens blijven in PostgreSQL
- De persistentie (RDB/AOF) verkleint het risico om de laatste seconden bij een crash te verliezen, maar neemt het niet volledig weg
- Vereist een nette invalidatiestrategie, anders kan het verouderde gegevens leveren
Kort oordeel
Gebruik Redis voor alles wat er meteen moet zijn — caching, sessies, winkelwagen, rate limiting, realtime en job queues. Zet het niet in als belangrijkste gegevensopslag; daarvoor blijft PostgreSQL verantwoordelijk. Op 4buildsite heb je ze allebei, automatisch op elkaar afgestemd: je hoeft niet te kiezen en niets in te stellen.
Specificatietabel
| Mogelijkheid | Detail | Gebruik in de builder |
|---|---|---|
| Latentie | < 1 ms (in-memory) | Gecachete pagina's en gegevens uit het geheugen |
| Doorvoer | > 100.000 bewerkingen/s per node | Veel verkeer, zonder dat de database instort |
| Datastructuren | String, Hash, List, Set, Sorted Set, Stream | Sessies, winkelwagen, ranglijsten, queues, rate limiting |
| Persistentie | RDB-snapshot en AOF-log | Snel herstel na een herstart |
| Verlooptijd | TTL per sleutel | Winkelwagen, sessies en cache die zichzelf opruimen |
| Realtime | Pub/sub en streams | Live voorraad, meldingen, bestelstatus |
Redis (cache) vergeleken met een oplossing met alleen een database
| Criterium | Met Redis | Alleen PostgreSQL |
|---|---|---|
| Responstijd bij herhaalde gegevens | minder dan 1 ms, uit het geheugen | tientallen milliseconden, een query bij elke aanvraag |
| Bij veel verkeer | database beschermd, schaalt makkelijk | database loopt vast, timeouts dreigen |
| Winkelwagen en sessies | met automatisch verlopen | groeiende tabellen die de database belasten |
| Realtime | pub/sub en streams standaard aanwezig | herhaald pollen, duur |
| Job queues | native, eenvoudig te gebruiken | geïmproviseerde oplossingen of helemaal geen |
Veelgestelde vragen
Wat is Redis, kort gezegd?
Een razendsnelle in-memory database die als laag voor cache, sessies en realtime vóór de hoofddatabase staat. Hij antwoordt in minder dan een milliseconde.
Waarom niet gewoon alleen PostgreSQL?
PostgreSQL is de bron van waarheid (blijvende gegevens), maar Redis levert herhaald opgevraagde gegevens in minder dan een milliseconde en neemt winkelwagen, sessies, rate limiting en realtime voor zijn rekening; daarmee beschermt het de database bij veel verkeer. De twee werken samen.
Verlies ik gegevens als Redis uitvalt?
Niet de inhoud van de website: de blijvende gegevens staan in PostgreSQL. In Redis staan alleen cache en tijdelijke gegevens, en de persistentie via RDB/AOF beperkt het verlies.
Moet ik Redis zelf instellen?
Nee. Het is inbegrepen en wordt beheerd door het platform 4buildsite; jij profiteert van de realtimefuncties, zonder iets te hoeven beheren.
Hoe helpt Redis een webshop?
Winkelwagen voor bezoekers, gecachete productlijsten, live bijgewerkte voorraad en bescherming tegen misbruik bij de kassa en bij formulieren — allemaal zonder de database te belasten.
Helpt Redis bij SEO en Core Web Vitals?
Indirect: korte responstijden van de server zijn een van de factoren die de TTFB en daarmee de Core Web Vitals beïnvloeden.