Een cachinglaag is een apart deel van een systeem met als enige taak: kant-en-klare kopieën van data bewaren en ze snel teruggeven. Hij zit tussen je applicatie en de tragere opslag erachter, zoals een database, en beantwoordt herhaalde verzoeken zonder elke keer de bron lastig te vallen.
Denk aan een druk koffietentje met een thermoskan verse koffie op de balie. Niet elke bestelling betekent een nieuwe slow brew; de barista schenkt uit de thermoskan en zet pas een nieuwe batch als die bijna leeg is. Die thermoskan is de cachinglaag: hij vangt de gestage stroom identieke bestellingen op zodat de trage machine erachter rust krijgt. In software is deze laag vaak een tool als Redis of Memcached, en hij bouwt voort op hetzelfde idee als gewone caching, alleen als eigen onderdeel.
Omdat hij meestal in het geheugen draait en niet op schijf, antwoordt een cachinglaag in ruim minder dan een milliseconde, veel sneller dan een rondje naar de database. Een veelgebruikt patroon heet “cache-aside”: de app kijkt eerst in de cache en raadpleegt de database alleen bij een misser, om dat resultaat daarna op te slaan voor de volgende keer. Je kunt er ook sessies, rate-limit tellers of berekende ranglijsten in bewaren die anders bij elk verzoek opnieuw opgebouwd moeten worden.
De afweging is versheid. Een kopie die te lang blijft staan kan verouderde data leveren, dus elke vermelding heeft meestal een vaste levensduur. Zet je dat verkeerd, dan dreigt het omgekeerde: een golf van verzoeken die allemaal tegelijk dezelfde waarde opnieuw opbouwen. Een cachinglaag combineren met technieken als connection pooling houdt de zware delen van een systeem rustig onder druk.
Bij TopDevs voegen we een cachinglaag toe als het verkeer van een klant dat rechtvaardigt, zodat de database gezond blijft en pagina’s snel blijven laden, ook op de drukste dagen.
