Cache, którego nie umiesz unieważnić, jest bugiem

Cache to zawsze obietnica

Każdy cache jest obietnicą złożoną użytkownikowi: „ta liczba jest prawdziwa". Nie „była prawdziwa dziesięć minut temu" - dla klienta nie ma takiej kategorii. Cena w koszyku jest ceną, stan jest stanem.

Dlatego pytanie „czy da się to zcache'ować" jest źle postawione. Zcache'ować da się wszystko. Właściwe pytanie brzmi: „skąd będę wiedział, że to przestało być prawdą".

Jeśli nie potrafisz odpowiedzieć, nie dodałeś optymalizacji. Dodałeś błąd, który pojawia się rzadko, nieregularnie i nie zostawia śladu w logach.

Trzy pytania przed dodaniem cache

Zanim wpiszesz Cache::remember, potrzebujesz trzech odpowiedzi.

Co jest kluczem? W B2C zwykle produkt. W B2B prawie nigdy - najczęściej (kontrahent, indeks), a przy progach ilościowych jeszcze koszyk. Klucz, który nie zawiera wszystkiego, od czego zależy wartość, to gwarantowany rozjazd. Ktoś zobaczy cudzą cenę i to jest gorsze niż wolny listing.

Co unieważnia wpis? Zmiana ceny w ERP. Zmiana cennika kontrahenta. Nowa promocja. Zmiana progu. Pytanie brzmi: czy ERP w ogóle powie ci, że coś z tego zaszło? Większość polskich ERP-ów nie ma webhooków, więc odpowiedź brzmi „nie" - i to zmienia całą architekturę, zanim napiszesz pierwszą linijkę.

Co się stanie, gdy się pomylisz? Nieświeży opis produktu to drobiazg. Nieświeży stan to zamówienie na towar, którego nie ma. Nieświeża cena to korekta faktury. Ta sama technika, trzy zupełnie różne progi ryzyka - i trzy różne TTL-e.

Dlaczego TTL to nie jest strategia

TTL jest deklaracją: „przez najbliższe piętnaście minut zgadzam się kłamać". To jest legalna decyzja, o ile jest decyzją, a nie wartością domyślną skopiowaną z tutoriala.

Problem z TTL polega na tym, że jest wygodny właśnie tam, gdzie jest najbardziej niebezpieczny. Cena z TTL 15 minut wygląda niewinnie, dopóki handlowiec nie zmieni cennika kontrahentowi i nie zadzwoni do niego z informacją, że już poprawione. Klient wchodzi, widzi starą cenę i wraca rozmowa od początku - tylko teraz z tezą, że „wasz system nie działa".

W B2B krótki TTL na cenę jest zwykle kompromisem akceptowalnym. Ale kompromis trzeba nazwać na głos i zapisać, a nie odkryć po fakcie. Warstwy cache i to, co gdzie ma sens, rozbieram w tekście o cache wielowarstwowym.

Co robić, gdy nie umiesz unieważnić

Zdarza się i nie jest to koniec świata. ERP nie ma webhooków, nie ma jak wykryć zmiany, a listing musi działać. Wtedy zostają trzy uczciwe wyjścia.

Skróć TTL do bólu. Minuta zamiast piętnastu. Mniej trafień w cache, ale ryzyko spada o rząd wielkości. Zwykle wystarcza, bo problemem nie było jedno zapytanie, tylko trzydzieści na listing.

Cache'uj transport, nie wynik. Zamiast trzymać policzoną cenę, trzymaj odpowiedź na batch „policz ceny dla tych trzydziestu indeksów". Odświeżasz jedną rzecz zamiast trzydziestu i masz jedno miejsce do unieważnienia.

Nie cache'uj w punkcie decyzji. Listing może pokazywać cenę sprzed minuty. Koszyk i składanie zamówienia - nigdy. Tam pytasz na żywo, bo tam kłamstwo kosztuje fakturę. Praktyczne strategie zebrałem w tekście o cache w wydajności.

Najgorsze wyjście to czwarte: dodać cache, nie zaprojektować unieważniania i uznać temat za zamknięty, bo listing przyspieszył. Ten cache i tak kiedyś skłamie. Tylko dowiesz się o tym od klienta, a nie z monitoringu.

Co dalej

• Warstwy cache i co gdzie ma sens: Cache wielowarstwowy
• Praktyczne strategie: Cache strategie
• Co dokładnie cache-ujesz przy cenie: Cenniki kontraktowe