Van trage API naar razendsnelle responses: Alles over caching in .NET

Waarom zou je cachen?

Stel, je bouwt een app die op basis van een naam een leeftijd raadt (zoals in de demo van de aflevering). Als ik “Sander” invul, is het antwoord altijd hetzelfde. Waarom zou je die berekening of die externe API-call tien keer opnieuw doen?

Caching is simpelweg het onthouden van het antwoord, zodat je het de volgende keer direct kunt teruggeven. Zeker bij data die ‘deterministisch’ is (dezelfde input = dezelfde output), is dit een no-brainer.

Optie 1: De snelle fix (In-Memory Cache)

De makkelijkste manier om te beginnen is de IMemoryCache. Dit zit standaard in .NET en slaat data op in het werkgeheugen (RAM) van de instantie die draait. De implementatie is laagdrempelig: met de methode GetOrCreateAsync controleer je of de data er is, en zo niet, haal je deze op en sla je hem direct op.

Voordelen:

• Eenvoud: Je hebt slechts één methode nodig (GetOrCreateAsync) die het ophalen en opslaan combineert.
• Snelheid: Omdat het in het RAM zit, praat je over nanoseconden.

Nadelen en Risico’s:

• Weg = weg: Start je je applicatie opnieuw op? Dan is de cache weer leeg.
• Load Balancing issues: In een productie-omgeving met meerdere instances (bijvoorbeeld achter een load balancer) loopt de cache niet synchroon. Een request naar instance A vult de cache daar, maar een volgend request naar instance B moet het werk opnieuw doen.
• Geen ‘Stampede Protection’: Dit is een groot risico bij high-traffic apps. Als een cache-entry verloopt en 100 gebruikers vragen tegelijk die data op, gaan er alsnog 100 requests dwars door je cache heen naar je database of externe API.

Optie 2: Het grotere werk (Distributed Cache)

Wil je het robuuster aanpakken, dan kom je uit bij een Distributed Cache via de IDistributedCache interface. Een populaire implementatie hiervoor is Redis. Hierbij draait je cache in een aparte container of service.

Het code-model verandert hier wel iets. Waar je bij In-Memory één handige methode had, moet je hier vaak zelf de logica splitsen: eerst een Get doen, checken of het null is, en anders de data ophalen en een Set doen.

De trade-off:

Je wint aan betrouwbaarheid (je app kan crashen terwijl je data in Redis blijft bestaan) en consistentie over meerdere servers heen. Je levert echter iets in op snelheid ten opzichte van In-Memory, omdat je nu een netwerk-call doet naar je Redis instantie.

Hybrid Cache

In de aflevering wordt een nieuwe feature van .NET geïntroduceerd: de Hybrid Cache. Microsoft probeert hiermee het gat te dichten door een ‘abstract class’ te bieden die het beste van twee werelden combineert.

Het idee is simpel maar krachtig: het gebruikt een snelle, lokale L1 cache (In-Memory) en synchroniseert dit met een grotere, gedeelde L2 cache (Distributed/Redis).

Belangrijke features:

• Uniforme API: Het brengt de geliefde GetOrCreateAsync stijl terug, waardoor je code schoner blijft dan bij een pure distributed cache.
• Stampede Protection: Dit zit er standaard ingebakken. Komen er 100 requests tegelijk voor een verlopen item? De Hybrid Cache laat er slechts één door naar de bron; de rest wacht netjes op het resultaat.

Nog meer functionaliteit nodig?

Vind je de standaard opties nog te basic? Dan is er FusionCache. Dit is de ‘grote broer’ waar Microsofts Hybrid Cache duidelijk inspiratie uit heeft gehaald.

FusionCache gaat verder waar de basis stopt. Een krachtig voorbeeld dat Jarne noemt is de Fail-safe mechaniek.

Stel je cache verloopt na 10 minuten, maar precies op dat moment ligt je database eruit. Normaal zou je app een error geven. Met FusionCache kun je instellen: “Als de bron onbereikbaar is, serveer dan de oude data nog maar 2 uur lang en probeer elke minuut de cache op de achtergrond te refreshen.” Dit houdt je applicatie in de lucht, zelfs als je backend problemen heeft.

Leuk detail: FusionCache heeft ook een implementatie van de hybrid cache abstractie, dit betekent dat je hybrid cache code kan schrijven en onder water fusion cache kan gebruiken. Dit is handig als je wil starten met HybridCache en later wil overschakelen naar fusion cache

Wat moet ik nu gebruiken?

Werk je aan een project op je eigen laptop? Begin met de In-Memory Cache. Het is de snelste weg naar resultaat.

Heb je meerdere instanties van dezelfde service draaien waarbij één centrale cache belangrijk is? Probeer dan Redis (Distributed Cache).

Wil je ‘future proof’ bouwen? Experimenteer dan met de Hybrid Cache. Hoewel het nog vrij nieuw is, biedt het (zeker in combinatie met tools als .NET Aspire) een hele moderne basis. Voor productie-apps die nu robuust moeten zijn, is FusionCache vaak de veiligste en meest feature-rijke keuze.