Czy Twój SaaS traci na zbyt wolnych odpowiedziach API? 3 lekcje z backendu

Pracuję z SaaS-ami od ponad dekady. I powiem Ci wprost: większość firm nie zdaje sobie sprawy, że ich API jest wąskim gardłem. Nie chodzi o to, że serwery padają – chodzi o to, że odpowiedzi przychodzą w 400 ms zamiast 50 ms. Brzmi niewinnie? Dla użytkownika to wieczność. Dla Twoich KPI – katastrofa.

W jednym z projektów, który audytowałem, firma traciła 20% użytkowników w trakcie onboardingu. Powód? API zwracało listę konfiguracji w 3 sekundy. Po optymalizacji do 100 ms wskaźnik konwersji wzrósł o 12%. Zero zmian w UI, tylko backend.

Oto trzy lekcje, które wyniosłem z realnych wdrożeń.

1. N+1 queries – cichy zabójca wydajności

ORM-y jak ActiveRecord czy Hibernate są wygodne, ale mają jedną pułapkę: generują zapytania w pętli. Jeśli pobierasz listę zamówień, a potem dla każdego zamówienia pobierasz szczegóły – boom, masz N+1 zapytań.

Przykład z życia:
Klient miał endpoint /orders który dla 100 zamówień wykonywał 101 zapytań do bazy. Każde zapytanie to 5 ms, więc łącznie ~500 ms. Po dodaniu eager loading i optymalizacji indeksów spadło do 15 ms. Różnica? 30x szybciej.

Co robić?

• Używaj eager loading (JOIN-y) zamiast leniwego ładowania.
• Monitoruj liczbę zapytań na endpoint – jeśli rośnie liniowo z danymi, masz problem.
• Rozważ użycie GraphQL, jeśli klienci często żądają różnych zestawów danych.

2. Brak cache’owania odpowiedzi – przepalasz moc obliczeniową

Wielu developerów myśli: „Po co cache’ować, skoro baza jest szybka?”. Ale baza nie jest szybka, gdy zapytanie dotyczy 50 tabel. A już na pewno nie jest szybka, gdy to samo zapytanie wykonuje 1000 użytkowników na sekundę.

Lekcja z projektu e-commerce:
Endpoint /products/popular był wołany przez każdą stronę główną. Bez cache’owania – 200 ms odpowiedzi. Z Redisem i TTL 30 sekund – 5 ms. Odciążyliśmy bazę o 90% zapytań.

Strategia:

• Cache’uj odpowiedzi, które są rzadko zmieniane (lista kategorii, konfiguracje).
• Używaj cache inwalidacji opartej na zdarzeniach – np. webhook gdy produkt się zmienia.
• Dla danych użytkownika rozważ cache per-user z krótkim TTL.

3. Zbyt duże payloady – wysyłasz niepotrzebne dane

Standardowy błąd: endpoint zwraca pełny obiekt z 50 polami, a klient potrzebuje tylko 3. To nie tylko marnuje przepustowość, ale też wydłuża czas serializacji i transferu.

Obserwacja z pola:
W jednym SaaS endpoint /user/profile zwracał cały rekord użytkownika (avatar w base64, historię logowań, preferencje). Payload ważył 300 KB. Po wprowadzeniu wersjonowania API i dedykowanych pól – spadł do 5 KB. Klient mobilny odetchnął.

Jak to naprawić?

• Używaj pól opcjonalnych (sparse fieldsets) – klient mówi, co chce.
• Paginuj listy – nikt nie potrzebuje 10 000 rekordów na raz.
• Kompresuj odpowiedzi (gzip, brotli).

Podsumowanie

Wolne API to nie problem serwerów – to problem architektury. Zanim kupisz kolejną instancję, spójrz na zapytania, cache i payload. Te trzy rzeczy często dają 10x poprawę bez ani jednego nowego serwera.

A jeśli potrzebujesz pomocy w audycie backendu – wiemy, jak to zrobić bez marketingowego lania wody.