Publiceren en binnen seconden live: hoe cache-invalidatie bij ons werkt

In het artikel over edge-caching legden we uit waarom je pagina's klaarliggen in Europese datacenters: daarom laden sites snel. Maar caching heeft een beruchte keerzijde, samengevat in het gezegde dat er maar twee moeilijke problemen bestaan in de informatica: dingen benoemen, en cache-invalidatie. Vandaag dat tweede probleem — want een zaakvoerder die zijn menukaart aanpast, wil niet horen dat de oude versie "nog ergens in een cache zit".

Het probleem in één zin

Een pagina die op tien edge-locaties gekopieerd klaarligt, moet bij een wijziging ook op tien plekken vervángen worden — en wel meteen, want voor de klant bestaat er maar één waarheid: wat er nú op de site staat.

De luie oplossing is korte cache-tijden ("bewaar alles maar vijf minuten"), maar dan gooi je het snelheidsvoordeel grotendeels weg. De botte oplossing is bij elke wijziging álles wissen, maar dan begint elke bezoeker na elke kleine aanpassing weer tegen een koude cache. Wij wilden allebei niet.

Hoe het bij ons werkt

Elke publicatie in het paneel triggert een gerichte opdracht aan het CDN: wis precies déze URL's. Het platform weet welke dat zijn, omdat het contentmodel de afhankelijkheden kent:

• De pagina zelf — uiteraard.
• Pagina's die de wijziging tonen — pas je een blogtitel aan, dan verandert ook de overzichtspagina en de RSS-feed; verander je een productprijs, dan ook de categoriepagina.
• Sitebrede wijzigingen — een nieuw menu-item of een andere themakleur raakt élke pagina, en dan wissen we bewust de hele site-cache in één keer. Zeldzaam genoeg om geen probleem te zijn, ingrijpend genoeg om het nooit te vergeten.

Binnen enkele seconden na "publiceren" halen de edge-locaties de verse versie op. De redacteur ziet zijn wijziging meteen; alle andere bezoekers ook.

Wat er misging toen we dit bouwden

Eerlijkheid hoort bij deze rubriek, dus drie lessen uit de bouwfase:

De vergeten meelifters. Onze eerste versie wiste braaf de gewijzigde pagina — en vergat de sitemap, de RSS-feed en de overzichtspagina's. Resultaat: een nieuw artikel dat live stond maar nergens opdook. De fix was structureel: niet per geval bedenken wat er mee moet, maar de afhankelijkheden uit het contentmodel afleiden, zodat een nieuw paginatype ze automatisch meekrijgt.

Redirects die bleven plakken. Een pagina van adres veranderen maakt een redirect aan — maar het óúde adres zat nog in de cache mét de oude inhoud. Sindsdien wissen we bij een padwijziging beide adressen: het oude en het nieuwe.

De race bij snelle tikkers. Wie twee keer binnen een seconde publiceert, kon heel even de eerste versie terug in de cache duwen. De oplossing is volgorde afdwingen: purges lopen per site in een wachtrij, nooit door elkaar.

Waarom dit voor jou telt

Vraag aan elke websiteleverancier met een CDN of cache: "hoe snel staat mijn aanpassing online, en moet ik daar iets voor doen?" De antwoorden variëren van "meteen" tot "binnen het kwartier" tot een uitleg over het legen van je browsercache. Bij ons is het antwoord kort: publiceren ís live gaan, binnen seconden, overal in Europa. De cache is ons probleem — precies zoals het hoort.