Co DNS naprawdę robi przy każdym żądaniu Każde żądanie do example.com zaczyna się od wyszukania, które nie ma nic wspólnego z twoją aplikacją: coś musi zamienić tę nazwę na adres IP, zanim jakikolwiek pakiet TCP opuści maszynę. Tym tłumaczeniem jest DNS, Domain Name System, i działa przy każdym żądaniu, niezależnie od tego, czy klientem jest przeglądarka, curl, czy usługa backendowa łącząca się z inną po hostname. Nie ma za tym jednej tabeli. DNS to hierarchia serwerów, z których każdy odpowiada za wycinek przestrzeni nazw, odpytywanych po kolei, aż przyjdzie odpowiedź. Znajomość tego łańcucha zamienia “strona nie działa” w “certyfikat wygasł” albo “rekord wciąż wskazuje na stary adres IP”: dwa zupełnie różne problemy, które z poziomu karty przeglądarki wyglądają identycznie. ...

Co TLS naprawdę chroni w połączeniu HTTPS Otwórz stronę przez zwykłe http:// w sieci, której nie kontrolujesz, na lotnisku albo na routerze w kawiarni, a wszystko, co wysyłasz, leci jako czytelny tekst. Ścieżka URL, ciasteczka, pola formularza, hasło w POST-cie logowania: każdy w tej sieci ze snifferem pakietów odczyta to w locie. TLS, Transport Layer Security, to protokół, który to blokuje. Siedzi między TCP a protokołem aplikacji, więc zanim HTTP zacznie w ogóle mówić, połączenie jest już zaszyfrowane i powiązane ze zweryfikowaną tożsamością serwera. HTTPS to po prostu HTTP puszczony przez takie połączenie zamiast przez zwykłe. ...

Każde wywołanie hostowanego API LLM wysyła Twój prompt na cudzy serwer i obciąża Cię opłatą za token. Zerwij połączenie z siecią, a przestanie odpowiadać. Ollama usuwa oba te problemy: pobiera model o otwartych wagach na Twoją maszynę i udostępnia go przez API REST na localhost:11434. Jeden plik binarny pełni rolę menedżera modeli, klienta czatu i serwera. Co Ollama robi naprawdę Ollama opakowuje llama.cpp i podobne silniki wnioskowania, więc nigdy nie musisz dotykać flagi kompilatora ani ścieżki do biblioteki CUDA. ollama pull llama3.2 pobiera skwantyzowany plik modelu (format GGUF) z własnego rejestru Ollama, a nie z Hugging Face, choć potrafi też importować pliki GGUF stamtąd. Uruchomienie modelu przekazuje te wagi do serwera działającego w tle, który ładuje je do RAM-u (lub VRAM-u, jeśli znajdzie kompatybilną GPU), trzyma je w pamięci przez kilka minut po ostatnim zapytaniu, żeby kolejne było szybkie, i zwalnia pamięć, kiedy zapytania przestają napływać. ...

Endpoint checkoutu, który zmniejsza obraz produktu, wysyła email z potwierdzeniem i aktualizuje silnik rekomendacji przed odpowiedzią 200 OK, jest tak szybki jak jego najwolniejszy krok. Jeśli którykolwiek z nich przekroczy limit czasu, cały request się wywala. Kolejka wiadomości pozwala endpointowi oddać tę pracę jako wiadomości i od razu odpowiedzieć, podczas gdy osobne workery odbierają je we własnym tempie. Co faktycznie robi kolejka wiadomości Kolejka wiadomości siedzi między dwiema częściami systemu, które nie muszą działać w tym samym momencie. Producer publikuje wiadomość opisującą pracę do wykonania. Kolejka ją przechowuje. Consumer ją odbiera, przetwarza i potwierdza. Te dwie strony nigdy nie rozmawiają ze sobą bezpośrednio. ...

Każdy zasób w chmurze, jaki kiedykolwiek stworzyłeś, klikając w konsoli webowej (VM, load balancer, rekord DNS), da się też opisać w pliku tekstowym i utworzyć jedną komendą. Plik trafia do git, przechodzi przez pull request i odtwarza ten sam setup na drugim koncie, bez konieczności pamiętania, które dziewięć ustawień zmieniłeś ręcznie. Dokładnie to robi Terraform. Co właściwie robi Terraform Terraform to open-source’owe narzędzie od HashiCorp, które zamienia infrastrukturę na pliki konfiguracyjne napisane w HCL (HashiCorp Configuration Language) i wprowadza je w życie przez API dostawcy chmury. Piszesz blok resource, opisujący bucket S3, instancję EC2 albo rekord DNS w Cloudflare, uruchamiasz terraform apply, a Terraform sam wylicza wywołania API potrzebne, żeby ten zasób powstał — a potem go śledzi, więc kolejny apply zmienia tylko to, co faktycznie się zmieniło. ...

Co CDN robi z żądaniem użytkownika Użytkownik w Tokio, który otwiera stronę hostowaną na serwerze w Wirginii, płaci za ten dystans dwa razy: raz za dotarcie żądania, raz za powrót odpowiedzi. Światłowód działa z ułamkiem prędkości światła, a sama ta podróż kosztuje już 150-200ms w obie strony, zanim serwer źródłowy w ogóle zacznie coś robić. Dołóż zapytanie do bazy danych i jeden czy dwa wolne przeskoki sieciowe, a strona, która tuż obok ładuje się natychmiast, po drugiej stronie globu wydaje się ociężała. ...

Zapytanie, które trwa 200ms w twojej bazie danych, nadal trwa 200ms za milionowym razem, gdy ktoś je uruchamia, a każde takie uruchomienie rywalizuje o te same połączenia, ten sam I/O dysku i ten sam procesor. Redis trzyma odpowiedź w pamięci, na serwerze, który nie robi niczego innego, więc milionowy odczyt kosztuje tyle co jeden przeskok sieciowy, a nie plan zapytania. Co Redis naprawdę robi jako cache Redis to key-value store działający w pamięci. Wartości żyją w RAM, więc odczyty i zapisy mierzy się w czasie poniżej milisekundy zamiast dziesiątek czy setek milisekund, które kosztuje zapytanie relacyjne, gdy w grę wchodzą joiny, obciążone indeksy albo zajęty connection pool. Redis stoi obok twojej bazy danych, nie zamiast niej: aplikacja pyta najpierw Redis i sięga do bazy dopiero, gdy Redis nie ma odpowiedzi. ...

Co stoi między przeglądarką a twoją aplikacją Wpisz w przeglądarce example.com, a żądanie nigdy nie dotrze bezpośrednio do procesu, który uruchamia twój kod. Najpierw trafia na coś innego: serwer, który odczytuje żądanie, decyduje, który backend ma odpowiedzieć, przekazuje je tam i odsyła odpowiedź tak, jakby sam ją wygenerował. Ten serwer to reverse proxy. Nginx, Caddy, Traefik i HAProxy robią dokładnie to samo, podobnie jak load balancer stojący przed klastrem Kubernetes. Układ się nie zmienia: klienci rozmawiają wyłącznie z proxy. Prawdziwe serwery zostają za nim, niezależnie od tego, ile ich jest i gdzie działają. ...

Robisz pull najnowszego main, a Git zatrzymuje się z CONFLICT (content): Merge conflict in checkout.js. Rozwiązujesz konflikt, a w logu pojawia się commit o nazwie Merge branch 'main' into feature/checkout, leżący na trzech commitach, które faktycznie napisałeś. Cztery commity, jedna prawdziwa zmiana. Kolega, który za miesiąc przeczyta tę historię, nie ma szans rozpoznać, który jest który. git merge i git rebase odpowiadają na to samo pytanie: jak zaktualizować swój branch o zmiany zrobione gdzieś indziej. Zostawiają za sobą bardzo różne ślady, a wybranie złego na wspólnym branchu robi realną szkodę. ...