API-svarstid under 100 ms: Caching-strategier med Redis och CDN

Den snabbaste databasfragan ar den du aldrig behover stalla, och den snabbaste berakningen ar den du redan har gjort. Det ar hela iden med caching: att spara resultatet av nagot dyrt sa att du kan ge tillbaka det direkt nasta gang nagon fragar. Vill du fa ner API-svarstider under 100 millisekunder ar ratt cachning ett av de mest kostnadseffektiva satten, eftersom man slipper kopa mer hardvara. Fel anvant blir det en kalla till buggar som ar svara att forsta. Har gar jag igenom hur jag tanker.

Tre lager som loser olika problem

Nar folk sager caching menar de ofta valdigt olika saker. Jag brukar dela upp det i tre lager. Ett CDN cachar statiskt innehall nara besokaren geografiskt. Redis eller en liknande nyckel-vardelagring cachar data som ar dyr att rakna fram eller hamta. Och applikationscache haller data i minnet i sjalva applikationen for det allra snabbaste atkomsten.

Poangen ar att de loser olika problem och ofta anvands tillsammans. Att forsta vilket lager som passar vilket problem ar halva jobbet. Att lagga allt i ett enda cachelager ar lika fel som att inte cacha alls.

Nar ett CDN ar ratt

Ett CDN ar nat av servrar runt om i varlden som haller kopior av ditt innehall nara besokaren. For bilder, skript, stilmallar och annat som ser likadant ut for alla ar det nastan alltid ratt forsta steg. Besokaren far svaret fran en server i narheten i stallet for fran din enda server pa andra sidan jordklotet, och din egen server slipper belastningen helt.

Modernt kan ett CDN aven cacha hela sidor eller API-svar som ar lika for manga anvandare. Det ar kraftfullt, men det ar ocksa har man maste borja tanka noga pa hur man tar bort gammalt innehall ur cachen nar nagot andras.

Nar Redis gor storst nytta

Redis kommer in nar det handlar om data som ar specifik for din applikation och dyr att rakna fram. Det kan vara resultatet av en tung databasfraga, en sammanstallning som tar tid att bygga, eller sessionsdata som maste delas mellan flera servrar. I stallet for att gora om jobbet for varje anrop sparar du resultatet i Redis och hamtar det darifran nasta gang.

• Cacha resultatet av tunga laser som kors ofta men dar datan sallan andras.
• Anvand det for sessioner och delat tillstand nar du kor pa flera servrar.
• Satt alltid en utgangstid sa att gammal data inte ligger kvar i all evighet.

Det svaraste ar att ta bort gammalt

Det finns ett gammalt skamt om att de tva svaraste sakerna i datavetenskap ar att namnge saker och att invalidera cache. Det ar sant. Att spara ett resultat ar enkelt. Det svara ar att veta nar resultatet har blivit foraldrat och behover raknas om. Cachar du for lange visar du gammal data, cachar du for kort tid forsvinner hela vinsten.

Jag brukar borja enkelt med en utgangstid som passar hur ofta datan andras. En produktkatalog som uppdateras dagligen tal en helt annan cachetid an ett saldo som maste vara korrekt i realtid. For data som maste vara fersk direkt nar den andras far man i stallet aktivt rensa cachen i samma stund som andringen sker. Min regel ar att hellre borja med kortare cachetider och forlanga dem nar man ser att det ar tryggt.

Vanliga fallgropar jag ser

Den vanligaste missen ar att cacha sadant som ar specifikt for en enskild anvandare i ett delat lager, sa att en anvandare plotsligt ser en annan anvandares data. Det ar bade en bugg och en sakerhetsrisk. En annan vanlig miss ar att inte ha nagon plan for vad som hander nar cachen ar tom, till exempel efter en omstart, sa att allt slar mot databasen samtidigt och systemet faller ihop precis nar det ska upp igen.

Min erfarenhet ar att caching ska laggas till medvetet och ett lager i taget, med matning fore och efter. Att stro cache overallt i panik nar nagot ar langsamt skapar fler problem an det loser. Konkreta exempel pa hur jag har lagt upp cachning i skarpa projekt finns i var casebook.

Mat traffsakerheten, inte bara narvaron

Att lagga till ett cachelager kanns produktivt, men utan matning vet man inte om det faktiskt gor nytta. Det matt jag bryr mig mest om ar hur stor andel av forfragningarna som besvaras direkt ur cachen i stallet for att ga vidare till databasen eller berakningen. Ar den andelen lag gor cachen knappt nytta, och da ar det battre att forsta varfor an att lita pa att den hjalper.

En lag traffsakerhet beror ofta pa att man cachar fel saker eller satter for korta utgangstider, sa att posterna hinner falla ur innan de hinner ateranvandas. Genom att titta pa den har siffran kan man justera vad som cachas och hur lange, och se effekten svart pa vitt. Det ar samma princip som loper genom hela texten: lagg till medvetet, mat resultatet och behall bara det som faktiskt bar frukt.

Relaterat

• Web Performance Audit: 15 åtgärder som ger 90+ Lighthouse-poäng
• Database query-optimering: 12 mönster som eliminerar N+1-problem
• Bundle-optimering för Next.js: Tree-shaking, code splitting och lazy loading

Vill du ta det vidare?

Om ditt system gor samma dyra arbete om och om igen kan vi ta ett forutsattningslost samtal dar vi tittar pa var ett cachelager skulle gora storst nytta. Las garna mer om hur jag jobbar med optimering eller titta i var casebook for konkreta exempel.