NestJS, Prisma i PostgreSQL w skali. Jak diagnozować wolną część serwerową, pulę połączeń i zapytania N+1

Skalowanie części serwerowej nie oznacza jednego ruchu infrastrukturalnego. W zestawie NestJS + Prisma + PostgreSQL skala jest sumą kilku ograniczeń: ile zapytań generuje jedna akcja użytkownika, ile danych pobiera widok aplikacji, ile połączeń utrzymują procesy Node.js, jak długo trwają transakcje, jak działają indeksy i czy krytyczne ścieżki da się szybko zdiagnozować.

NestJS daje strukturę: moduły, kontrolery, dostawców, wstrzykiwanie zależności, strażników dostępu, przechwytywacze, walidację, kolejki i połączenia z innymi systemami. Prisma daje dostęp do bazy z bezpieczeństwem typów i czytelny model danych. PostgreSQL daje silnik transakcyjny, indeksy, JSONB, blokady, plan wykonania i kontrolę nad danymi. Skala pojawia się wtedy, gdy te trzy warstwy pracują jako jeden system, a nie trzy osobne technologie.

Dlatego w diagnozie nie zaczynamy od opinii o narzędziu. Zaczynamy od ścieżek użytkownika: logowanie, lista zamówień, finalizacja zamówienia, wyszukiwarka, panel administracyjny, import danych, raport, zdarzenie zewnętrzne i synchronizacja z systemem finansowo-magazynowym. Dopiero potem patrzymy, który element architektury jest wąskim gardłem.

Średnia odpowiedź części serwerowej potrafi ukryć system, który zaczyna się rozpadać. Jeśli 90% żądań działa w 120 ms, ale finalizacja zamówienia, import albo lista zamówień czasem trwa 4-8 sekund, użytkownik i tak odczuwa produkt jako niestabilny. Przy skali liczy się ogon: p95, p99, przekroczenia czasu odpowiedzi, ponowienia, błędy 5xx i liczba żądań czekających na połączenie z bazą.

Minimalna diagnostyka powinna obejmować powiązanie ścieżki komunikacji w NestJS z zapytaniami Prisma i planem PostgreSQL. Prisma Query Insights może pokazać, które zapytania są wolne, kosztowne i skąd pochodzą. Prisma dokumentuje też przypisywanie zapytań przez komentarze SQL, co pomaga powiązać SQL z modelem, akcją i kształtem zapytania ORM.

W praktyce GMI szuka wzoru, nie pojedynczego wolnego żądania. Czy problem rośnie w godzinach szczytu? Czy dotyczy jednej ścieżki komunikacji czy całej bazy? Czy p95 rośnie po wdrożeniu, po imporcie danych, po kampanii marketingowej, po dodaniu filtra w sprzedaży internetowej? Bez tej odpowiedzi przebudowa jest zgadywaniem.

PostgreSQL ma limit jednoczesnych połączeń. Dokumentacja PostgreSQL opisuje `max_connections` jako maksymalną liczbę równoczesnych połączeń i ostrzega, że zwiększenie tej wartości podnosi alokację zasobów, w tym pamięć współdzieloną. To ważne, bo “dajmy 1000 połączeń” nie jest darmowym skalowaniem.

Prisma Client automatycznie łączy się przy pierwszym zapytaniu, tworzy pulę połączeń i zwykle nie wymaga ręcznego `$connect()` ani `$disconnect()`. Dokumentacja Prisma ostrzega jednak, że tworzenie wielu instancji `PrismaClient` może wyczerpać pulę połączeń, zwłaszcza w środowiskach bezserwerowych albo uruchamianych blisko użytkownika. W klasycznym serwerze należy współdzielić jedną instancję klienta.

Przy wielu procesach NestJS, automatycznym skalowaniu, procesach roboczych, zadaniach w tle i zdarzeniach zewnętrznych problem potrafi wrócić mimo poprawnej jednej instancji klienta. Wtedy rozważa się PgBouncer albo Prisma Accelerate. Prisma dokumentuje, że zewnętrzne narzędzie do puli połączeń działa między Prisma Client a bazą i redukuje liczbę procesów, które baza musi obsłużyć w danym momencie. Dla PgBouncera Prisma wymaga trybu transakcyjnego.

Problem N+1 występuje wtedy, gdy aplikacja pobiera listę rekordów, a potem dla każdego rekordu wykonuje dodatkowe zapytanie. Prisma pokazuje ten problem na przykładzie GraphQL: funkcja pobierająca listę użytkowników wykonuje jedno zapytanie, a funkcja pobierająca ich wpisy uruchamia kolejne zapytanie dla każdego użytkownika. Przy 50 użytkownikach robi się 51 podróży do bazy.

Prisma ma narzędzia do walki z N+1, ale trzeba rozumieć ich granice. Dokumentacja wskazuje grupowanie `findUnique()` przez mechanizm zbierający podobne zapytania oraz możliwość użycia `relationLoadStrategy: "join"`, żeby wykonać zapytanie przez JOIN i ograniczyć liczbę zapytań do bazy. To nie jest jednak magiczny przełącznik dla każdej ścieżki komunikacji z aplikacją. Czasem JOIN jest najlepszy, czasem dwa mniejsze zapytania są bezpieczniejsze dla pamięci i planu wykonania.

Drugi problem to pobieranie zbyt szerokiego zakresu danych. `include` bywa wygodne, ale potrafi pobierać całe sieci relacji, których ekran albo ścieżka komunikacji z aplikacją nie potrzebuje. W ścieżkach krytycznych GMI preferuje świadome `select`, obiekty danych projektowane pod konkretny przypadek użycia i osobne zapytania dla danych, które nie muszą być częścią pierwszej odpowiedzi.

PostgreSQL przypomina w dokumentacji, że indeksy przyspieszają odnajdywanie konkretnych wierszy, ale dodają narzut do całego systemu, więc trzeba ich używać sensownie. To jest sedno pracy przy skalowaniu: indeks powinien pasować do realnego filtra, sortowania, zakresu dat, identyfikatora klienta, statusu zamówienia albo wyszukiwarki, a nie tylko do pola, które “może kiedyś się przyda”.

W systemach sprzedażowych i dla klientów firmowych często pojawia się JSONB: parametry produktu, konfiguracje, dane z połączeń zewnętrznych, zdarzenia z innych systemów, odpowiedzi systemu finansowo-magazynowego. PostgreSQL ma rozbudowane operatory i ścieżki JSON, ale JSONB nie powinien być wymówką dla braku modelu biznesowego. Jeśli filtr staje się krytyczny dla sprzedaży albo panelu operacyjnego, trzeba rozważyć indeks, denormalizację, widok zmaterializowany albo osobną tabelę.

Prisma dobrze opisuje relacje i typy, ale nie zdejmie z zespołu odpowiedzialności za plan zapytania. W GMI patrzymy, czy model danych odpowiada pytaniom biznesowym: “pokaż dostępne produkty w magazynie”, “pokaż zamówienia wymagające interwencji”, “policz marżę dla kampanii”, “znajdź klientów zagrożonych odejściem”. Jeśli model tego nie wspiera, samo przepisywanie kodu nie wystarczy.

W dojrzałej części serwerowej Prisma i surowy SQL nie są religiami, tylko narzędziami. Prisma powinna zostać tam, gdzie wygrywa bezpieczeństwo typów, szybkość prac, czytelność domeny i powtarzalne operacje tworzenia, odczytu, aktualizacji oraz usuwania danych. Surowy SQL ma sens tam, gdzie ścieżka komunikacji jest krytyczna biznesowo, plan zapytania musi być kontrolowany ręcznie albo ORM utrudnia użycie konkretnej funkcji PostgreSQL.

Typowe miejsca dla surowego SQL to ciężkie raporty, panele nad milionami rekordów, wyszukiwarki z rankingiem, operacje hurtowe, okna czasowe, CTE, widoki zmaterializowane, blokady, skomplikowane agregacje i fragmenty, w których zespół musi analizować `EXPLAIN ANALYZE` linia po linii. To nie oznacza rezygnacji z Prismy w całym projekcie.

Największy błąd to przepisywanie wszystkiego “bo ORM jest wolny”. Taka przebudowa często niszczy tempo zespołu i nie usuwa prawdziwego problemu. Lepszy model: zostaw 80-90% typowego kodu w Prisma, a najbardziej kosztowne 10-20% ścieżek przenieś do świadomie zaprojektowanych funkcji zapytań, testów regresji i wglądu w działanie systemu.

NestJS dokumentuje, że domyślnie używa Express, ale może korzystać z innych bibliotek przez adaptery, na przykład Fastify. Dokumentacja wskazuje Fastify jako szybszą alternatywę w testach porównawczych i dobry wybór, gdy bardzo wysoka wydajność HTTP jest priorytetem. To jest przydatne, ale nie powinno być pierwszym ruchem przy wolnej części serwerowej.

Jeśli 80% czasu żądania schodzi w bazie, zmiana adaptera HTTP nie naprawi produktu. W NestJS najpierw sprawdzamy cykl obsługi żądania: walidację, przechwytywacze, serializację, strażników dostępu, pamięć podręczną, wywołania zewnętrzne, kolejki, transakcje i liczbę zapytań Prisma na ścieżkę komunikacji. Dopiero potem decydujemy, czy Fastify, proces roboczy, kolejka, pamięć podręczna albo podział modułu ma sens.

Dla systemów GMI najważniejsza jest przewidywalność. Część serwerowa systemu sprzedażowego albo operacyjnego powinna mieć limity, przekroczenia czasu odpowiedzi, zasady ponawiania prób, idempotencję, kontrole zdrowia systemu, ograniczanie liczby żądań, ustrukturyzowane zapisy zdarzeń, śledzenie zdarzeń i ostrzeżenia. Bez tego skala jest szczęściem, nie architekturą.

Naprawa części serwerowej w produkcji wymaga sekwencji, nie heroicznego zrywu. Najpierw trzeba zatrzymać krwawienie: ograniczyć najdroższe ścieżki komunikacji z aplikacją, dodać limity czasu odpowiedzi, wyłączyć niekrytyczne zadania w tle, zabezpieczyć pulę połączeń i odzyskać wgląd w działanie systemu. Dopiero potem można zmieniać model danych albo przepisywać zapytania.

W rozpoznaniu biznesu, projektu i technologii GMI zbiera kod, schemat Prisma, migracje, zapisy wolnych zapytań PostgreSQL, metryki chmury, listę ścieżek komunikacji, wolumen danych, połączenia z innymi systemami, zadania w tle, oczekiwania biznesowe i okna wdrożeniowe. Wynikiem nie jest ogólna rekomendacja “trzeba zoptymalizować”. Wynikiem jest mapa ryzyk, kolejność działań, zakres pierwszej sensownej naprawy i decyzja, czy da się to wycenić w stałej cenie.

Najlepsze naprawy są nudne: jedno krytyczne połączenie mniej w czasie obsługi żądania, jeden indeks mniej ryzykowny, jedna transakcja krótsza, jedna kolejka odciążająca czas odpowiedzi, jeden panel diagnostyczny więcej. Po kilku takich krokach system przestaje być tajemnicą i zaczyna być zarządzalny.