Guava cache, a ddos

Przy danym endpoincie używam cache z guavy.

        cache = CacheBuilder.newBuilder()
            .maximumSize(10_000)
            .expireAfterWrite(200, TimeUnit.MILLISECONDS)
            .build()

Wartosc z cache ma sie usuwac po 200ms.

Pytanie: Co w przypadku jeśli ktoś np. naśle atak ddos np. 5000requestów, a średnio moja cachowana operacja wykonuje się np. 500ms?
Chodzi o to, że jeśli będzie moment w którym wartość z cache po tych 200ms zostanie usunięta to żeby reszta (około 5k~) requestów nie brała się za obliczanie tej operacji która jest cachowana.

Czy cache guavy oferuje jakieś zabezpieczenie przed czymś takim? Lockowanie nie wchodzi w gre

A nie możesz po prostu trzymać cache dłużej niż 200ms?

Kamil Żabiński napisał(a):

A nie możesz po prostu trzymać cache dłużej niż 200ms?

Też sugerowałem takie rozwiązanie, niestety zostało ono odrzucone. Kompletnie nic innego mi nie przychodzi do głowy, stąd pytanie tutaj

Ogólnie wartość w cache trzyma się tak długo jak tylko:

• Wartość w cache jest dalej poprawna (bo np. nie zmienia się w czasie )
• Nie brakuje w systemie pamięci

Czyli jeśli wartość nie będzie wymagać ponownego przeliczenia i pamięci nie będzie brakować to można ustawić expireAfterWrite na jeden dzień/tydzień/miesiąc/rok/. Gorzej jak po jakimś czasie dane stają się niepoprawne, albo obawiasz się że nie starczy pamięci. Na ten drugi wypadek można przenieść wartość expireAfterWrite to propertisów żeby móc to konfigurować na produkcji. Lub w jakiś inny sposób to zmieniać.

Innym rozwiązaniem może być zewnętrzny cache jak Redis

Kamil Żabiński napisał(a):

Ogólnie wartość w cache trzyma się tak długo jak tylko:

• Wartość w cache jest dalej poprawna (bo np. nie zmienia się w czasie )
• Nie brakuje w systemie pamięci

Czyli jeśli wartość nie będzie wymagać ponownego przeliczenia i pamięci nie będzie brakować to można ustawić expireAfterWrite na jeden dzień/tydzień/miesiąc/rok/. Gorzej jak po jakimś czasie dane stają się niepoprawne, albo obawiasz się że nie starczy pamięci. Na ten drugi wypadek można przenieść wartość expireAfterWrite to propertisów żeby móc to konfigurować na produkcji. Lub w jakiś inny sposób to zmieniać.

No właśnie ten cache tyczy się endpointa z health checkiem, więc dane się mają szansę stać niepoprawnymi, jak np. się apka wyje@$ie.

Z tego co wiem health checkiem zwykle nie wystawia się na świat zewnętrzny

Jakie rozwiązanie już przerabialiście?

Rozważaliście np.:

1. Usługi anty-DDOS (nie używałem, nie znam wad/zalet, po prostu rzucam pomysłem) jeśli to ruch z zewnątrz
2. Więcej instancji aplikacji w zapasie żeby rozłożyć ruch (napisaliście posty w trakcie pisania mojego, wiec dla HC to raczej nie ma sensu)
3. Jeśli to niepubliczne api to nałożyć limit req/s na usera (jeśli od HC zależy coś ważnego to chyba też odpada)
4. Wzięcie na klatę requesty i przyduszenie apki, ale user przynajmniej dostanie odpowiedź. Poczekacie na zeskalowanie się aplikacji albo umrzecie jeśli ruch będzie zbyt duży (tu też w przypadku HC skalowanie nie ma sensu)

znalazłem rozwiązanie, temat do zamknięcia.