W przypadku 1 zwracałbym błąd, bo inaczej aplikacja działa dość dziwnie, bo jeden user jest w stanie korzystać (bo jest w cache), a drugi nie i może to rodzić problemy.
No takiego problemu nie będzie, bo chodzi tu o dane niekrytyczne, więc obaj użytkownicy mogą korzystać. Cache jest jeden, więc wszyscy użytkownicy mają dostęp do tych samych danych, czyli co najwyżej jeden user dodatkowe informacje zobaczy, drugi nie. Ale tak może się przecież stać nawet bez cache, bo np. danych może oryginalnie nie być od początku.
W przypadku 2, o ile nie ma jakichś biznesowych gwarancji na to eventual consistency i to nie są jakieś krytyczne dane (typu access-control) to trzymałbym stary stan jeśli nie da się zbudować bardziej aktualnego.
No czyli moja opcja 1.
Dla mnie cache to takie rozwiązanie problemu szybkości dostępu do danych. Dorzucanie jakiejś logiki, że cache coś tam aktualizuje i pobiera zewnętrznego systemu, ociera się o złamanie SRP (nie zakładam, że rozwiązanie jest obiektowe, ale zasadę można trochę ekstrapolować ;-) ).
No tak, masz rację, to był skrót myślowy z mojej strony. Chodziło mi o klasę, która jest elementem jakiegoś procesu w systemie i zawiera w sobie cache przechowujący dane a także klienta pobierającego dane ze źródła. Tylko to szczegóły implementacji, niezbyt istotne w kontekście problemu.
Odpowiadając na Twoje drugie pytanie - dane do tego faktycznego cache wstawia ta klasa podczas pierwszej potrzeby jej użycia.
no skoro cache to optymalizacja czasu/kosztu dostepu do danych to gdy danych nie ma to cache przestaje miec znaczenie. jesli cache ma pelnic role "backupu" to zwykle prowadzi to do roznych problemow zwiazanych ze ustalaniem co i kiedy jest prawidlowe. dlatego lepiej te dwie funkcjonalnosci (t.j. cache i backup) separowac jak najwczesniej bo potem w miare dokladania nowych "featuresow" jest tylko gorzej
Dobrze, więc niech będzie backup, a nie cache. Jak to zmienia odpowiedź? :)
Moim zdaniem to serwer (jako właściciel danych, źródło prawdy) powinien sterować ważnością danych, które serwuje poprzez np. ustawienie nagłówka Cache-Control.
Pewnie tak, ale tego nie robi.
Zresztą, to to nie zawsze musi mieć sens, bo te same dane mogą mieć różną ważność w różnych kontekstach, a kontekst znają konsumenci, a nie serwer.
Czasem mamy cache, który zakładamy bez świadomości serwera, żeby ograniczyć ruch. W momencie, kiedy serwer padnie zachowałbym się tak samo, jakby tego cache nie było - jeśli minie TTL, to zwracam 503.
Tak, o takim przypadku tutaj mowa, ale o zwracaniu 503 z powodu braku opcjonalnych danych nie ma mowy.
Logika czyszczenia cache (tutaj od razu czerwona lampka) w zależności od zdrowia źródła danych to kiepski pomysł, bo trzeba w jakoś sposób czyścić cache na wszystkich instancjach itd - tutaj fajny wątek: https://www.quora.com/Why-is-cache-invalidation-considered-difficult
No jeśli źródło jest niedostępne, to wszystkie instancje w tym samym czasie nie będą mogły pobrać z niego danych, więc np. cache się samo wyczyści. Nie widzę problemu.