AWS transformeert Amazon ElastiCache tot persistente datastore

Amazon ElastiCache verwerkt wereldwijd miljarden verzoeken per seconde met microseconde-latentie. Hoewel Multi-AZ replicatie en automatische failover voor de meeste caching-toepassingen volstonden, vormde het risico op dataverlies bij storingen een barrière voor bedrijfskritische workloads. Met de introductie van een Multi-AZ transactioneel logboek biedt AWS nu twee smaken van duurzaamheid aan, zonder dat dit ten koste gaat van de kenmerkende leessnelheid.

Twee opties: Synchroon vs. Asynchroon

Ontwikkelaars kunnen binnen ElastiCache voor Valkey (vanaf versie 9.0) kiezen uit twee duurzaamheidsstrategieën, afhankelijk van de tolerantie voor dataverlies en de vereiste schrijfsnelheid:

1. Synchrone Schrijfacties (Synchronous Writes) – Zero Data Loss
Deze optie is ontworpen voor scenario's waarin elk verloren bit kritiek is. Schrijfacties worden pas door het systeem bevestigd naar de client nadat ze hardnekkig zijn weggeschreven in het transactionele logboek over ten minste twee Availability Zones (AZ's). Dit garandeert strong consistency op de primaire nodes.

Latentie: Leenacties blijven binnen microseconden; schrijfacties verhuizen door de netwerk-roundtrip naar single-digit milliseconden.

Ideaal voor: Lange-termijngeheugen van AI-agents, statusbeheer van AI-workflows, kennisbanken voor RAG-systemen, betalingstokenisatie en realtime voorraadbeheer.

2. Asynchrone Schrijfacties (Asynchronous Writes) – Maximale Snelheid
Voor workloads waarbij data weliswaar hersteld kan worden, maar het herbouwen vanaf de bron te tijdrovend of kostbaar is, biedt asynchroon uitkomst. Hierbij reageert de database direct met een microseconde-schrijflatentie, waarna de data op de achtergrond naar het Multi-AZ logboek wordt gestreamd.

Latentie: Zowel lezen als schrijven gebeurt binnen microseconden (vrijwel identiek aan ElastiCache zonder duurzaamheid).

Dataverlies-grens: Maximaal 10 seconden. AWS introduceert hiervoor een durability buffer. Mocht de achterstand naar het logboek (DurabilityLag in CloudWatch) door netwerkcongestie de 10 seconden passeren, dan weigert de primaire node tijdelijk nieuwe schrijfacties totdat het logboek is bijgewerkt. Lezen blijft wel mogelijk.

Ideaal voor: Sessiebeheer, gaming leaderboards en realtime analytics.

Prestatieanalyse: Microseconden blijven de norm

Om aan te tonen dat duurzaamheid de prestaties niet onderuithaalt, heeft AWS benchmarks uitgevoerd op r7g.4xlarge-nodes met een gemengde workload (80% lezen, 20% schrijven) op 50K en 100K transacties per seconde (TPS).

Uit de tests blijkt dat de asynchrone optie qua latentie nauwelijks afwijkt van de traditionele non-durable variant. Zelfs bij de synchrone variant blijft de leeslatentie bij gematigde workloads (50K TPS) ruim onder de 300 microseconden, wat bewijst dat de architectuur geoptimaliseerd is voor lees-intensieve enterprise-omgevingen.

Beschikbaarheid en Implementatie

De duurzaamheidsfunctionaliteit is per direct beschikbaar in alle commerciële AWS-regio's voor clusters die draaien op Valkey 9.0 of hoger. Bestaande clusters kunnen via de AWS CLI of de AWS Management Console zonder downtime worden omgezet tussen synchrone en asynchrone modi via het commando modify-replication-group.

AWS adviseert ontwikkelaars die gebruikmaken van asynchrone clusters om automatische retries met exponential backoff in te richten in hun client-applicaties voor het geval de 10-secondenbuffer wordt overschreden. De officiële opensource-clientbibliotheek Valkey GLIDE ondersteunt deze functionaliteit inmiddels standaard.