Wstęp
API Gateway to jedno z tych rozwiązań, które w teorii brzmi jak srebrna kula: centralny punkt kontroli ruchu między klientem a backendem, gotowy na obsługę autoryzacji, throttlingu, agregacji danych. W praktyce, gdy przyjrzę się architekturze sklepów e-commerce, które tracą na wydajności lub bezpieczeństwie, często źródłem problemu jest właśnie źle skonfigurowany lub błędnie zaprojektowany API Gateway.
Widzę to na co dzień: klienci, którzy przyszli z „szybkim fixem” do swojego sklepu, a okazuje się, że problem leży w warstwie, która miała wszystko upraszczać. W tym artykule pokażę trzy najczęstsze błędy, które popełniają zespoły (często pod presją czasu lub budżetu) i które realnie windują koszty, spowalniają sklep lub tworzą luki bezpieczeństwa.
Błąd #1: API Gateway jako monolityczne „śmietnisko” logiki biznesowej
Znam przypadek sklepu z odzieżą, który zatrudnił zewnętrzny zespół do migracji z monolitów na mikroserwisy. Chcieli być nowocześni. Niestety, zaprojektowali API Gateway tak, że przechowywał logikę biznesową dotyczącą koszyka, promocji i walidacji adresów. Brzmi wygodnie? Tylko do momentu, gdy trzeba wprowadzić nową promocję – cały Gateway musiał być redeployowany, co blokowało inne endpointy.
Efekt: czas wdrożenia funkcji promocyjnych wydłużył się z 2 dni do 2 tygodni, a przy okazji spadła dostępność API podczas każdej aktualizacji. Gdy próbowali skalować tylko część odpowiedzialną za koszyk, musieli skalować cały Gateway – marnowali zasoby.
Na czym polega błąd?
API Gateway powinien być warstwą przekierowującą i agregującą, a nie magazynem logiki. Każda reguła biznesowa w Gatewayu to potencjalny punkt awarii i opóźnienie w iteracji. Jeśli Twoja logika koszyka lub promocji siedzi w Gatewayu, masz złą architekturę.
Jak to naprawić?
Przenieś całą logikę biznesową do dedykowanych mikroserwisów. Gateway niech tylko routuje, autoryzuje (na podstawie tokena JWT) i ewentualnie agreguje odpowiedzi z kilku serwisów – bez żadnej logiki warunkowej „jeśli promocja i kupon to…”. Do tego służą serwisy domenowe.
Błąd #2: Brak throttlingu i rate limitingu (lub zbyt agresywny)
Ostatnio audytowałem sklep z elektroniką, który przygotowywał się do Black Friday. Ich API Gateway był skonfigurowany bez żadnego rate limitu – każdy klient mógł wysłać tyle żądań, ile chciał. Podczas promocji złośliwy bot (lub zepsuty skrypt) zaczął wielokrotnie odpalać endpoint koszyka, generując przeciążenie bazy danych i opóźnienia dla prawdziwych klientów. Sklep stracił ok. 15% konwersji podczas peaku.
Z drugiej strony, znam startup SaaS, który ustawił zbyt restrykcyjny throttling – klient, który normalnie wysyłał 100 żądań na minutę (bo integracja API), nagle dostawał błędy 429 po 20 żądaniach. Uznali, że to błąd po stronie klienta, ale tak naprawdę problemem była zbyt niska konfiguracja.
Jak dobrać odpowiednie limity?
Nie ma uniwersalnej liczby. Kluczowe jest profilowanie ruchu w Twoim e-commerce. Zbierz dane przez miesiąc: jakie endpointy są najczęściej wywoływane, ile żądań generuje typowy użytkownik, a ile boty. Następnie ustaw limity na poziomie 1,5-2x typowego ruchu. Warto też wprowadzić warstwę API key dla partnerów (większy limit) i osobny dla anonimowych użytkowników (mniejszy).
Błąd #3: Ignorowanie modelowania czasu odpowiedzi – bramka jako bottleneck
Częsty scenariusz: sklep korzysta z API Gateway jako punktu wyjścia do wszystkich serwisów – również dla żądań wymagających dużych danych, jak listy produktów z obrazkami. Gateway agreguje odpowiedzi z serwisu produktów, promocji i magazynu. Problem pojawia się, gdy backend produktów odpowiada wolno (np. 500 ms), a Gateway czeka na wszystkie serwisy, zanim zwróci odpowiedź do klienta. Klient czeka 1,5 sekundy, a bezpośrednie połączenie z serwisem produktów dałoby 200 ms.
Znam przypadek platformy marketplace, która próbowała agregować dane z 5 serwisów dla strony głównej. Gateway stawał się wąskim gardłem – czas odpowiedzi wzrósł z 300 ms do 3 sekund. Próby skalowania Gatewayu na 10 instancji nie pomogły, bo bottleneckiem była agregacja synchroniczna.
Jak temu zaradzić?
Po pierwsze, ustal SLA dla każdego endpointu. Jeśli klient potrzebuje szybkiej odpowiedzi, użyj asynchronicznych wzorców (np. CQRS lub event-driven). Po drugie, wprowadź caching dla rzadko zmieniających się danych (produkty, kategorie). Gateway może cache’ować odpowiedzi na minutę lub dwie, co drastycznie zmniejsza obciążenie backendu. Po trzecie, rozważ użycie wzorca Backend for Frontend (BFF) – osobnego Gatewayu dla klienta mobilnego i webowego, co pozwoli dostosować agregację do konkretnego przypadku użycia.
Podsumowanie
API Gateway potrafi zdziałać cuda w e-commerce, ale tylko jeśli jest prawidłowo użyty. Unikaj umieszczania logiki biznesowej w samej bramce – to rola serwisów. Dbaj o właściwy throttling – nie za luźny, nie za ciasny. I modeluj czas odpowiedzi, aby Gateway nie stał się wąskim gardłem.
Jeśli masz wrażenie, że Twój sklep działa wolno, a IT twierdzi, że backend jest szybki – sprawdź API Gateway. To często tam tkwi problem, nie w serwerach czy bazie danych. U nas w JurskiTech regularnie pomagamy firmom refaktorować warstwę API – efektem jest często 30-50% wzrost szybkości strony i mniej awarii w szczycie sezonu.
