17 · Kubełkowanie

Ten wpis jest o ograniczeniu, którego nikt nie szuka, dopóki się o nie nie potknie. Wpisy leżały płasko w katalogu serii. Kilkanaście plików — w porządku. Sto dwadzieścia — nadal w porządku, choć katalog robi się nieczytelny. Kilka tysięcy — i zaczynają się kłopoty, przy czym nie w silniku i nie w hostingu, tylko w narzędziach wokół repozytorium.

Rozwiązanie jest banalne: wpisy dzielone na podkatalogi po roku publikacji. Zmiana dotyczy wyłącznie układu plików, bo silnik i tak skanuje katalog treści wzorcem, a nie po liście.

Warto zatrzymać się nad tym, że wzorzec skanowania okazał się tu zaletą, o której nie myśleliśmy, wybierając go. Gdyby gdziekolwiek istniała lista plików do zaktualizowania, ta zmiana byłaby przepisaniem tej listy. Ponieważ nie istnieje, była przeniesieniem plików.

Ogólniejsza obserwacja: wąskie gardła w takich systemach rzadko siedzą tam, gdzie się ich szuka. Szukaliśmy ich w rozmiarze odpowiedzi i w limitach czasu procesora. Znalazło się w liczbie plików w katalogu — czyli w warstwie, o której nikt nie myśli jako o części architektury.

Stąd zasada, którą staramy się teraz stosować: przy każdej rzeczy, która rośnie liniowo z liczbą wpisów, zadaj pytanie, co się stanie przy dziesięciu tysiącach. Nie żeby od razu optymalizować — żeby wiedzieć, gdzie jest ściana.