Wat we ermee bouwen
Redis bewaart de data die een service onmiddellijk nodig heeft en opnieuw zou kunnen aanmaken als hij ze kwijtraakte. Gecachte queryresultaten die anders bij elk verzoek de database zouden raken, sessiestaat, tellers voor verzoeklimieten, kortlevende locks, en de taakwachtrijen die traag werk uit het verzoekpad halen.
Dat laatste is meestal de grootste winst in een product. Een e-mail versturen, een document genereren of een externe API aanroepen hoort niet binnen het HTTP-verzoek waarop een gebruiker wacht — dat op een wachtrij zetten is wat een pagina responsief houdt wanneer een dienst verderop een slechte dag heeft.
Waar het past
Vóór PostgreSQL, niet in plaats daarvan. Het patroon dat we gebruiken is met opzet saai: de relationele database bezit de waarheid, Redis bezit alles wat het waard is niet opnieuw te berekenen, en elke sleutel heeft een vervaltijd zodat een verouderde cache een tijdelijk probleem is en geen blijvend.
Wanneer we het aanraden
Wanneer een specifieke query meetbaar heet is, wanneer je achtergrondtaken nodig hebt, of wanneer staat gedeeld moet worden tussen meerdere instanties van een service.
Niet als eerste zet. Een cache toevoegen voordat je weet wat traag is, levert je een tweede systeem om te beheren op en een nieuwe soort bug — data die op de ene plek klopt en op de andere niet. Meet eerst, cache daarna wat het profiel werkelijk aanwijst.
