Z tego co tu czytam, to cały ten system oparty jest o bazę danych bez warstwy pośredniej na poziomie domeny czy nawet cache
...
Pierwszy sklep internetowy stworzyłem w 1996, na własnym silniku, w Perlu, dla dużego wydawnictwa. Obecny silnik pracuje pod dużym obciążeniem (w świątecznym szczycie dochodzi do 200 req/sek), na sporym wolumenie danych (kilkadziesiąt GB baza produkcyjna), więc wybacz, ale nie potrzebuję rad jak optymalizować frontend, zaoszczędź swój czas, chyba, że to piszesz dla innych ludzi.
Natomiast narasta problem częstych aktualizacji cen, więc nawet jeżeli jest cache (używam Memcached) i inne rozwiązania, to po co zamulać serwer i I/O, jeżeli zamiast kopiowania całego rekordu produktu przy aktualizacji małej cząstki danych, będziemy trzymać ceny w osobnej tabeli.
Natomiast ta zmiana wymaga sporo pracy, jeszcze nie miałem czasu robić testów, żeby zobaczyć czy to się w ogóle opłaca, jak zrobię to się tutaj podzielę wnioskami.
PS. tworzenie wielu pośrednich warstw, mikroserwisów, rozproszenia na wiele serwerów to jest coś czego wolę uniknąć tak długo jak się da, na razie wolę "modularny monolit". To jest po prostu bardzo drogie i pracochłonne, już bardziej wolę takie rozwiązania jak replikacja, partycjonowanie, loadbalancing modularnego monolitu, archiwizacja starszych danych do bazy archiwum niż grzebanie z mikroserwisami.
Mikro są fajne na papierze, i kiedy chodzi o coś małego, natomiast przełożenie dużej skomplikowanej aplikacji na setki mikroserwisów to są ogromne koszta. Allegro zatrudnia ponad tysiąc programistów (takie dostałem info sam nie mogę w to uwierzyć), tak dużo potrzeba, żeby utrzymać i rozwijać ich aplikację REST + różne poboczne rzeczy związane z tym systemem.
PPS. Allegro na LinkedIn, ponad 2 tys. pracowników: https://www.linkedin.com/company/allegro-pl/