Patch pliku w Storage - unieważnienie cache w CDN

[GKotfis]

W naszym rozwiązaniu zauważalny stał się problem opóźnień, pomiędzy aktualizacją pliku w Storage, a jego odświeżenie w CDN.
Chodzi o zdjęcia profilowe użytkowników w aplikacji mobilnej. Infrastruktura w tym zakresie nie zmieniła się od kilku miesięcy, ale w ostatnim czasie zaczęły spływać problemy, że zdjęcie nie jest odświeżane po ponownym restarcie appki. Aktualnie trzeba czekać ok 1-2 minut.
Po pierwsze - nie wiem, dlaczego tak zaczęło się dziać :) Storage jest na jeden region (US), CDN także. Prócz tego, że po prostu systematycznie się powiększa (aktualnie ok 7GB, Hot) za wiele sie tam nie dzieje. Szukam jakiegoś usprawnienia tego problemu. Na pierwszy rzut przychodzą mi takie rozwiązania jak:

1. Custom caching rules dla ścieżki. Przy czym tutaj nie widzę opcji ścieżki z dwoma wilcardami '*', np. user/*/profile/* więc nie jestem w stanie objąć jakiekogolwiek użytkownika i jego zdjęcia, które jest w podfolderze profile.
2. Użycie REST SDK i funkcji, która reaguje na PATCH Bloba i wykonuje request do https://management.azure.com ... docs.microsoft.com/en-us/rest/api/cdn/endpoints/purge-content

Coś jeszcze polecicie?

[ptrstpp950]

A co masz ustawione w caching rules ? Chodzi mi o tą dokumentację: Control Azure CDN caching behavior with caching rules plus nagłówki

[GKotfis]

Wygląda na "by default"

[ptrstpp950]

No dobra a jakie header zwraca Azure Storage jak uderzysz do niego bezpośrednio? Nie mam nic pod ręką i obstawiam, że daje coś co każe CDN przechowywać te pliki dłużej.
Możesz zrobić 2 eksperymenty, który pokażą dokładniej gdzie jest problem:

1. Uderzyć "curl" do Azure CDN i zapisać wynik łącznie z headers na dysk
2. Wgrać nowe zdjęcie
3. Puścić curl do Azure CDN w pętli aż dostaniesz nowe zdjęcie
   Drugi jest analogiczny tylko strzelasz bezpośrednio do storage ;)
   Ewentualnie powtórzyć 1 i 2 z przeglądarką, bo ona ma cache i może z niego skorzystać

I teraz może wyjść, że:

1. Problem jest w apce która po prostu ma cache request i go nie wykonuje (a powinna zrobić HEAD i sprawdzić ETag) i wtedy może się okazać że to apka się zmieniła i dlatego nagle zachowuje się inaczej ;)
2. Azure CDN za długo trzyma plik - tutaj problem jest trudniejszy, ale niestety inaczej niż przez powyższą stronę go nie rozwiążesz. Możesz spróbować dla plików "profile" zrobić except (zakładam że plik z profilówką zawsze nazywa się tak samo, bo inaczej nie miałbyś problemu, bo byłoby to żądanie o nowy query string i wtedy ścieżka może być /users/*selfiak.jpg )
3. Azure Storage robi cache - tutaj jedynie "nowy query string" Cię uratuje.

[GKotfis]

Dzięki @ptrstpp950
W kwestii cache i profilówki to totalnie przestrzeliłem z założeniami jak to działa. Każda profilówka użytkownika to nowy blob (z random UUID). Więc cache CDN nie ma tu znaczenia bo idzie nowy URL. Założyłem, że to cache bo po zmianie zdjęcia w request widziałem ten sam url (z tymi sami UUID). Okazało się, że nie zawsze nowy URL do profilu użytkownika jest aktualizowany w jego właściwościach w DB.
A za tą aktualizację odpowiada funkcja odpalana BlobTrigger. W logice tej funkcji jest wykorzystany ContentModerator z CognitiveServices, który sprawdza czy dana fotka "się nadaje". Weryfikacja dwóch właściwości: IsImageAdultClassified oraz IsImageRacyClassified
Niestety w przypadku gdy zdjęcie nie przechodzi weryfikacji, nie jest w to żaden sposób komunikowane użytkownikowi ani jakkolwiek obsługiwane przez backend :)

Ciekaw jestem czy ta weryfikacja miała rzeczywiści mieć miejsce, czy jednak ktoś robił CV driven development :D