Wybór podstawy systemu buforującego był prosty. Ogromne możliwości konfiguracyjne squid'a, jego duża wydajność i skalowalność oraz brak kosztów z tytułu licencji nie pozostawiły wielkiego wyboru. W układzie tutaj zaprezentowanym proxy pełnią dwie role. Pierwsza to izolacja maszyn webowych od publicznej sieci, Druga to oczywiście cache.

Niestety sam squid nie jest wystarczający. Większość serwisów dzisiaj budowanych jest zupełnie dynamicznie. Na co dzień spotykamy aplikacje, które budują serwis opierając się na bazach danych dynamicznie generując zawartość. Bardzo dużo pracy trzeba więc poświecić na projektowanie aplikacji oraz stosowanie rozwiązań które 'dają się' zapamiętać w cache. Najprostszym przykładem są tutaj CMS'y. Rynek pełny jest CMS'ów pozwalających na budowanie witryn webowych w prosty sposób jednak w większości działają one tak, że treść serwisu jest za każdym razem generowania. Można jednak spróbować przyjrzeć się CMS'om potrafiącym wygenerować statyczną treść, która w łatwy sposób będzie cache’owana. Ma to ogromne znaczenie ze względu na wydajność, wystarczy wyobrazić sobie, że udźwignięcie kampanii reklamowej kierującej na strony dynamicznie generowane będzie wymagało wielokrotnie większych zasobów niż w sytuacji, gdyby treść była ustatyczniona.

Czy treści, które wprowadzamy zawsze muszą być generowane on-line? Wystarczy przecież, że zdamy sobie sprawę, iż publikacja może być przeprowadzana np. w 5ciominutowych odstępach czasu. Zysk jest ogromny i warty rozważenia, ponieważ koszt utrzymania jednego czy dwóch serwerów jest wielokrotnie niższy niż farmy serwerów generujących treść dynamicznie. Dodatkowo farma serwerów proxy jest wtedy w stanie ustatycznioną zawartość zamieścić w cache i obsługując ruch w ogóle nie obciążać serwerów webowych czy aplikacyjnych.

Czasami trzeba również znaleźć pośrednie rozwiązania pozwalające zbuforować tylko cześć treści serwisu, gdzie pozostałe elementy są spersonalizowane. W takim przypadku projektanci aplikacji powinni bardzo dużą uwagę zwracać na ustawienie odpowiednich nagłówków stron webowych tak, aby mechanizmy buforowania rozpoznały co można i na jaki czas zapamiętać ze (?) strony w formie statycznej.

Jeśli połączymy to wszystko z mądrymi mechanizmami równoważenia obciążenia to okaże się że dobrze jest czasem uruchomić aplikacje obsługujące np. personalizacje serwisu na dodatkowych serwerach i kierować na nie ruch na podstawie decyzji load balancera. Wtedy przy odpowiedniej konfiguracji ruch statyczny rozpoznany przez LB będzie kierowany do farmy proxy, natomiast elementy dynamiczne powędrują na kilka serwerów aplikacyjnych.

Wszystko to potrafi ograniczyć koszty utrzymania infrastruktury nawet do 80%, a przy bardzo dużych systemach bywa, że jest to kwota naprawdę warta rozważenia.