„Uścisk śmierci" – analiza techniczna infrastruktury, która przeżyła (i nie przeżyła) finał zbiórki Łatwoganga

Zastrzeżenie metodologiczne: Poniższa analiza opiera się na publicznie dostępnych informacjach, obserwacjach zachowania systemów podczas eventu oraz standardach branżowych SRE. Wewnętrzna architektura SiePomaga i Tipply nie jest publicznie udokumentowana. Tam, gdzie piszemy o przyczynach i mechanizmach awarii, przedstawiamy nasze hipotezy i najbardziej prawdopodobną rekonstrukcję zdarzeń – nie twierdzenia oparte na bezpośrednim dostępie do systemów. Rekomendacje architektoniczne są natomiast oparte na sprawdzonych wzorcach inżynieryjnych i stanowią naszą propozycję dla platform planujących podobne eventy.

Jako inżynierowie w SparkSome odpowiedzialni za środowiska o wysokiej dostępności (High Availability), definiujemy Flash Crowd jako gwałtowny, skoordynowany skok ruchu generowany przez miliony użytkowników bez naturalnego momentu wytchnienia. 26 kwietnia 2026 roku o godz. 21:37 to zjawisko uderzyło w polską infrastrukturę z siłą bez precedensu: ponad 251 milionów złotych zebrane w 9 dni, kulminacyjne 1 544 003 jednoczesnych widzów i szczytowy ruch transakcyjny szacowany na 150 000 żądań HTTP na sekundę (RPS) – wzrost o 122% względem poprzedniego rekordu Polski. W tym artykule rozkładamy ten przypadek na czynniki pierwsze, analizując prawdopodobne źródła problemów i proponując konkretne rekomendacje architektoniczne.

Dlaczego 150 000 RPS to „uścisk śmierci" dla infrastruktury?

Liczba 150 000 RPS nie robi wrażenia bez kontekstu. Porównanie z poprzednimi rekordami polskiego internetu pokazuje skalę wyzwania:

* Dane z wykresu opublikowanego oficjalnie przez SiePomaga (Metabase). Dotyczą wyłącznie ruchu na stronie skarbonki SiePomaga – nie obejmują Tipply, Zrzutka.pl ani wpłat bezpośrednio na konto bankowe.

Kluczowa różnica vs. Black Friday: flash-sale trwa minuty. Szczyt Łatwoganga trwał godziny, z nakładającymi się falami wywoływanymi przez momenty streamowe (rekordy kwotowe, wejście Tede, Bedoesa, Borysa Szyca). Architektura musiała utrzymywać throughput 100 000+ RPS nieprzerwanie przez wiele godzin.

Rozproszony ekosystem platform – dane, którymi dysponujemy to tylko wycinek

Liczba 251 mln PLN to suma zebrana jednocześnie przez kilka niezależnych kanałów: SiePomaga (główna skarbonka), Tipply (wpłaty przez stream na YouTube), Zrzutka.pl oraz bezpośrednie wpłaty na konto bankowe. Każda z tych platform obsługiwała własną infrastrukturę – i każda miała własny punkt awarii.

Jedyne oficjalne potwierdzenie przeciążenia infrastruktury pochodzi od SiePomaga, która wprost napisała: „Nasze serwery płonęły, a programiści pracowali w pocie czoła cały weekend, by udźwignąć tę falę dobra." Zrzutka.pl nie wydała żadnego oficjalnego komunikatu, jednak zewnętrzne obserwacje wskazują, że platforma przestała odpowiadać w kulminacyjnych momentach eventu. Nie mamy żadnych danych z wnętrza Tipply ani informacji o skali wpłat bezpośrednio na konto.

Oznacza to, że szacowane 150 000 RPS to ruch rozproszony po wszystkich platformach łącznie. SiePomaga sama w sobie miała szczyt ok. 540 000 jednoczesnych użytkowników na stronie skarbonki, co już samo w sobie stanowiło obciążenie bez precedensu. Cały ekosystem razem był wielokrotnie większy. Analizując poszczególne komponenty, operujemy na danych cząstkowych – co tylko wzmacnia wagę naszych rekomendacji architektonicznych.

Positive Feedback Loop (pętla dodatniego sprzężenia zwrotnego): to mechanizm, w którym wyjście systemu wzmacnia jego wejście. Subathon był jego perfekcyjnym przykładem: każda wpłata przedłużała stream, każde przedłużenie przyciągało nowych widzów, każdy widz potencjalnie wpłacał na kolejne przedłużenie. W odróżnieniu od typowego flash-sale, który ma naturalny moment wytchnienia po wyczerpaniu puli atrakcyjnych produktów, subathon nie miał żadnego wewnętrznego mechanizmu wyhamowania. Dla inżynierii infrastruktury oznaczało to jedno: szczyt mógł być wyższy i dłuższy niż cokolwiek, co systemy widziały wcześniej.

Chronologia finału i moment przełomu

Skala wydarzeń zaskoczyła prawdopodobnie wszystkich, w tym inżynierów odpowiedzialnych za infrastrukturę. Zbiórka rosła przez 9 dni w tempie imponującym, ale możliwym do przewidzenia. Finałowy dzień, 26 kwietnia 2026, był inny: od około 16:00 ruch zaczął rosnąć wykładniczo wraz z zapowiedzią końca zbiórki i mobilizacją społeczności. O 20:00, gdy zbliżał się pierwotny termin zakończenia, transmisja została przedłużona, bezpośrednio w odpowiedzi na falowe obciążenie systemów płatniczych i lawinę wpłat. Kulminacja nastąpiła o 21:37.

To ważny kontekst dla każdej analizy technicznej: cel architektoniczny nie polegał na obsłudze dużej zbiórki, lecz na obsłudze zdarzenia, którego pełna skala stała się widoczna dopiero w ostatnich godzinach. Nikt nie wiedział, że tego wieczoru 150 000 równoległych żądań na sekundę stanie się rzeczywistością. To zmienia ton tego artykułu z oceniającego na wyciągający wnioski: zadajemy pytanie nie co zostało zepsute, lecz co warto przygotować na przyszłość.

Jak mógł wyglądać stack pod 150 000 RPS? Nasz model referencyjny

Wewnętrzna architektura SiePomaga i Tipply nie jest publicznie udokumentowana. Wiemy, że SiePomaga korzysta z Cloudflare i Kubernetes, natomiast Tipply bazuje na AWS i Cloudflare, uzupełnionych o OVH. Na tej podstawie oraz standardów branżowych SRE rekonstruujemy prawdopodobny model referencyjny. Traktuj tę tabelę jako naszą hipotezę roboczą, nie dokumentację systemów.

Wzorce wysokiej dostępności (HA), które prawdopodobnie przeżyły próbę obciążenia

Zebranie 251 mln PLN bez całkowitej awarii jest samo w sobie sukcesem inżynieryjnym. Na podstawie zewnętrznych obserwacji wnioskujemy, że następujące elementy prawdopodobnie zadziałały prawidłowo.

Cloudflare jako filtr ruchu na poziomie edge

Cloudflare prawdopodobnie pochłonął zdecydowaną większość ruchu HTTP dla zasobów statycznych, chroniąc origin serwery. Przy milionach jednoczesnych użytkowników oznaczałoby to, że warstwa aplikacyjna otrzymała ułamek rzeczywistego natężenia. Decyzja o streamowaniu na YouTube (nie własna infrastruktura wideo) była strategicznie słuszna: YouTube przejął najtrudniejszy element, dostarczenie strumienia do 1,5 mln widzów jednocześnie.

Atomowy licznik zbiórki jako kręgosłup real-time

Operacje INCRBY na Redis są z natury atomowe, co eliminuje ryzyko race condition przy milionach równoległych zapisów. Zakładamy, że prawidłowo zaimplementowany Redis w trybie on-demand mógł skalować się do setek tysięcy operacji zapisu na sekundę bez interwencji inżynierskiej.

Brak całkowitej awarii jako dowód częściowej odporności systemu

Fakt, że zbiórka dotarła do 251 mln PLN mimo obserwowanych problemów (błędy 502/504, opóźnienia TTS, niespójności licznika), sugeruje, że krytyczna ścieżka płatności miała przynajmniej częściową odporność na awarie. Ewentualne problemy miały charakter degradacji UX, nie utraty serwisu.

Analiza wąskich gardeł: Dlaczego Aurora PostgreSQL mogła ulegać nasyceniu zapisu?

Na podstawie zewnętrznych obserwacji (raporty użytkowników, zachowanie licznika, opóźnienia TTS) formułujemy hipotezy dotyczące najprawdopodobniejszych przyczyn degradacji. Nie dysponujemy dostępem do logów ani metrycznych danych wewnętrznych.

Hipoteza: blokady wierszy (Row Locks) i sufit IOPS w bazie relacyjnej

Zakładamy, że każda donacja wymagała sekwencji operacji zapisu: INSERT nowej płatności, UPDATE licznika kampanii i INSERT do audit logu. W typowej architekturze relacyjnej (PostgreSQL, Aurora PostgreSQL) oznacza to trzy blokujące operacje per transakcja. Przy nawet 5 000 donacji na minutę generuje to 15 000+ operacji zapisu na minutę na jednym węźle writer. To klasyczna write saturation, która jest prawdopodobnym źródłem rosnących opóźnień P99 obserwowanych podczas szczytu.

Konsekwencją byłaby eskalacja na wyższy poziom: blokady wierszy (row locks) przy transakcyjnej aktualizacji głównego licznika. Systemy bez rozproszonych liczników tworzą w takich warunkach zatory – każda wpłata czeka w kolejce na zwolnienie blokady poprzedniej, co liniowo wydłuża czas odpowiedzi wraz ze wzrostem ruchu.

Rekomendacja SparkSome: Sharded Counters.

Zamiast jednego wiersza blokującego wszystkie równoległe zapisy, system utrzymuje N niezależnych wierszy (shardów), z których każdy przyjmuje 1/N całkowitego ruchu. Blokada na jednym shardzie nie wstrzymuje pozostałych. Aktualna kwota zbiórki to suma wszystkich shardów, obliczana asynchronicznie. W połączeniu z Redis jako primary counter i PostgreSQL jako audit store, taka architektura powinna obsłużyć 200 000 RPS bez degradacji latencji P99.

Hipoteza: błędy 504 jako objaw przeciążonej warstwy aplikacyjnej

Masowe raporty użytkowników o błędach 502 Bad Gateway i 504 Gateway Timeout są charakterystyczne dla sytuacji, w której warstwa proxy (Cloudflare) nie otrzymuje odpowiedzi od origin w ustawionym oknie czasowym. Cloudflare standardowo czeka na odpowiedź przez 60 sekund. Naszym zdaniem najbardziej prawdopodobna przyczyna to kombinacja: przeciążona warstwa aplikacyjna (OOM lub kolejka zapytań do bazy) + czas procesowania transakcji przekraczający limit timeout Cloudflare przy dużych kolejkach do bazy relacyjnej.

Hipoteza: Thundering Herd na warstwie cache Redis

Obserwowane niespójności wartości licznika mogą wskazywać na klasyczny Thundering Herd: gdy TTL wpisu w Redis wygasa w momencie szczytu, miliony klientów jednocześnie odpytują bazę o aktualny stan. Zamiast jednego zapytania odświeżającego cache, baza relacyjna dostawałaby lawinę równoległych żądań w chwili, gdy była już bliska nasycenia.

Rekomendacja SparkSome: wzorzec stale-while-revalidate.

Zamiast pozwolić, by wygaśnięcie cache uderzyło bezpośrednio w bazę, system przez kilka sekund serwuje poprzednią wartość licznika, podczas gdy jeden dedykowany worker asynchronicznie odświeża wpis w Redis. Użytkownicy widzą wartość sprzed kilku sekund zamiast strony błędu. Uzupełnieniem jest operacja Redis INCRBY, która z natury jest atomowa i eliminuje race condition przy równoległych zapisach. Write-behind caching domyka architekturę: wpłaty są agregowane w Redis, a do bazy relacyjnej trafiają zbiorczo, co redukuje ciśnienie na bazę transakcyjną o ok. 80–90%.

Efekt Retry Storm – gdy darczyńcy stają się nieświadomymi atakującymi

Retry Storm (burza ponownych prób): użytkownicy nie widząc potwierdzenia wpłaty wielokrotnie odświeżali stronę i ponawiali płatność. Każdy taki odruch tysięcy osób generował nową falę ruchu nieodróżnialną od ataku DoS. Mechanizmy Rate Limiting Cloudflare zaczęły odcinać uczciwych darczyńców. Samonapędzający się cykl chaosu.

Trwałe rozwiązanie wymaga Idempotency-Key (klucz idempotentności) w każdym żądaniu płatności – unikalnego identyfikatora, dzięki któremu system rozpoznaje redundantne próby wpłaty. Ta sama operacja wykonana wielokrotnie daje ten sam wynik co wykonana raz. Standard zaimplementowany przez Stripe i Adyen – brakuje go w polskich bramkach.

Redundancja DNS – dlaczego jeden dostawca to za mało?

Jeden z wniosków z analizy eventu dotyczy architektury DNS. SiePomaga i Tipply korzystają z Cloudflare – solidnego wyboru. Jednak nawet najlepszy dostawca DNS może doświadczyć przeciążeń lub incydentów podczas globalnych skoków ruchu. Uzależnienie od jednego dostawcy na poziomie DNS to SPOF (Single Point of Failure – pojedynczy punkt awarii), którego warto uniknąć przy eventach tej skali.

Rekomendacja SparkSome: Multi-Cloud DNS.

Rozproszenie rekordów między dwóch niezależnych dostawców (np. Cloudflare DNS + Amazon Route 53 jako fallback) eliminuje ten SPOF. W połączeniu z konfiguracją Multi-region dla warstw krytycznych i automatycznym failoverem poniżej 30 sekund, system staje się odporny na niedostępność jednego dostawcy. To rekomendacja prewencyjna – nie reakcja na konkretny incydent.

Bramki płatnicze i Fintech – najsłabsze ogniwo polskiej infrastruktury

BLIK i bramki obsługujące zbiórkę pełniły rolę krytycznego ogniwa w procesie monetyzacji. Przy wolumenie zbliżonym do 251 mln PLN w ciągu kilku dni wydajność tych systemów była testowana ekstremalnie.

Mechanizm przeciążenia bramek – rate limiting uderza w darczyńców

Zewnętrzne bramki płatnicze są projektowane z myślą o standardowym ruchu handlowym, czyli setkach, najwyżej tysiącach transakcji na minutę per merchant. Zbiórka Łatwoganga generowała wielokrotnie więcej żądań, uderzając w kilka ograniczeń jednocześnie.

Bramki posiadają twarde limity API: przekroczenie progu inicjacji płatności od jednego sprzedawcy skutkuje odpowiedzią HTTP 429 Too Many Requests. Każda transakcja BLIK wymaga dodatkowo synchronicznej autoryzacji po stronie banku wydawcy, co wprowadza punkt latencji całkowicie poza kontrolą bramki. Webhooki potwierdzające płatność ustawiały się w kolejce, powodując opóźnienia w potwierdzeniach sięgające kilku minut – i to właśnie ten mechanizm był bezpośrednim generatorem Retry Storm po stronie użytkowników. Niska marża operatora idzie przy tym często w parze z mniejszymi nakładami na redundancję infrastruktury, co zmniejsza odporność systemu na ekstremalne obciążenie.

Problem nie był ekonomiczny. Był architektoniczny: bramki płatnicze nie były projektowane na synchronizowany Flash Crowd z milionami widzów na YouTube, którzy w tej samej sekundzie reagują na rekord kwotowy widoczny na żywo.

Circuit Breaker i Idempotency-Key: mechanizmy obronne przed Retry Storm (burzą ponownych prób)

W warunkach ekstremalnego obciążenia samo skalowanie zasobów jest niewystarczające. Rekomendujemy wdrożenie wzorca Circuit Breaker (wyłącznik automatyczny), który automatycznie przerywa zapytania do nasyconej bazy danych lub bramki płatniczej i przełącza ruch na alternatywną bramkę (np. PayU lub Adyen) – zamiast bombardować przeciążoną usługę kolejnymi żądaniami.

Równocześnie, aby zneutralizować skutki Retry Storm, rekomendujemy pełną implementację Idempotency-Key. Dzięki temu unikalnemu identyfikatorowi przypisanemu do każdego żądania system rozpoznaje redundantne próby wpłaty. Nawet jeśli darczyńca kliknie „Wpłać" dziesięć razy w ciągu minuty, backend inicjuje tylko jedną transakcję.

Queue-First Architecture (architektura kolejkowa): Jak uniknąć Retry Storm przy zbiórce na 500 mln PLN?

Pięć fundamentalnych rekomendacji SparkSome dla platform zbiórkowych, systemów płatniczych i architektów systemów cloud.

1. Queue-First Architecture (architektura kolejkowa) – asynchronizacja jako fundament

Synchroniczny model żądanie-odpowiedź (klik bezpośrednio do bramki) nie skaluje się powyżej kilkuset transakcji na sekundę. Rekomendujemy wzorzec oparty na kolejce komunikatów (np. Amazon SQS FIFO lub RabbitMQ):

1. Żądanie płatności wpada do kolejki – użytkownik dostaje natychmiastowe potwierdzenie przyjęcia
2. Worker pool przetwarza donacje we własnym tempie (throttled), dostosowanym do możliwości bramki
3. Webhook od bramki trafia do serwisu aktualizującego licznik
4. Redis INCRBY (operacja atomowa) aktualizuje stan w czasie rzeczywistym
5. WebSocket / SSE pushuje aktualizację do milionów klientów

Kluczowy zysk: UX jest natychmiastowy („Dziękujemy za wpłatę!"), backend pracuje we własnym tempie. Bramka płatnicza nigdy nie otrzymuje więcej żądań niż jest w stanie obsłużyć. Retry Storm staje się niemożliwy z założenia architektonicznego.

2. Provisioned Concurrency (zarezerwowana moc obliczeniowa) – eliminacja burst limit w warstwie compute

Warstwy compute (AWS Lambda, Kubernetes pods) mają regionalne limity wzrostu. Skok ruchu z YouTube może być zbyt gwałtowny dla standardowego mechanizmu auto-scaling: warstwa compute zaczyna zwracać błędy 429 i throttlować żądania, zanim skalowanie zdąży zareagować. W przypadku AWS Lambda rekomendujemy rezerwację Provisioned Concurrency na poziomie minimum 5 000 instancji dla funkcji obsługujących inicjację płatności i rejestrację donacji przed planowanym szczytem. Reserved Concurrency = 8 000 stanowi górny limit chroniący pozostałe funkcje przed zagłodzeniem zasobów. Alarm na throttle rate powyżej 0,5% pozwala zespołowi SRE zareagować, zanim problem dotrze do użytkownika.

3. Graceful Degradation (kontrolowane obniżanie jakości) – cztery poziomy awaryjne

Każdy komponent systemu musi mieć zdefiniowany tryb działania na wypadek przeciążenia: nie pełna funkcjonalność albo całkowita awaria, lecz kontrolowane obniżanie jakości usługi. Poniżej cztery poziomy degradacji, które rekomendujemy:

4. Multi-Cloud DNS i Geo-Redundancja – odporność na niedostępność dostawcy

Rozproszenie rekordów DNS między dwóch dostawców eliminuje SPOF (pojedynczy punkt awarii) na warstwie rozwiązywania nazw. Systemy krytyczne powinny umożliwiać przełączenie ruchu do innego dostawcy chmurowego w przypadku awarii głównego regionu. Minimum produkcyjne: konfiguracja Multi-AZ + automatyczny failover < 30 sekund.

5. Obligatoryjne load testy (testy obciążeniowe) – etyczny obowiązek platformy charytatywnej

Nieudana płatność podczas zbiórki charytatywnej to utrata darowanej kwoty, nie tylko zły UX. Rekomendujemy load test symulujący 3× przewidywany peak TPS na 4 tygodnie przed planowanym eventem. Narzędzia: k6, Gatling lub AWS Distributed Load Testing. Kryterium sukcesu: P99 latencja endpointu płatności < 500ms, error rate < 0,1%.

Jak przygotować system na zbiórkę 500 mln PLN? Prognoza inżynierska

Po tym wydarzeniu żadna polska platforma zbiórkowa nie może twierdzić, że nie wiedziała o możliwości tej skali. Następna zbiórka musi być zaprojektowana na 500 mln PLN, nie 250 mln.

Zebranie 250 mln PLN przez system, który przeżył to sukces misyjny. Zebranie 500 mln PLN przez system, który działał bez zarzutu to cel inżynieryjny. Te dwa standardy różni kilka miesięcy świadomego przygotowania architektonicznego i wola organizacji, by potraktować inżynierię niezawodności jako element misji, a nie koszt.

Wnioski: inżynierski triumf w warunkach ekstremalnych

Mimo zdiagnozowanych (lub przypuszczanych) wąskich gardeł, finał zbiórki należy uznać za ogromny sukces operacyjny. Skala przedsięwzięcia przeskoczyła wszelkie modele prognostyczne i historyczne benchmarki. Systemy nigdy całkowicie nie przestały procedować darowizn, co jest prawdziwym dowodem odporności przy zdarzeniu tej bezprecedensowej skali.

Wielkie chapeau bas dla zespołów technicznych SiePomaga, Tipply oraz partnerów płatniczych. Walka o każdą milisekundę czasu odpowiedzi, żywe reagowanie na kolejne fale ruchu i utrzymanie ciągłości zbierania środków mimo momentów spowolnienia to dowód na wysoką dojrzałość operacyjną. Analiza, którą przeprowadzamy, jest ćwiczeniem zewnętrznym opartym na danych publicznych: nie wiemy, jak wyglądała rzeczywista architektura ani jakie decyzje inżynierskie podejmowano w czasie rzeczywistym. Wynik mówi sam za siebie.

FAQ – najczęstsze pytania po lekturze

Czy błędy 502/504 oznaczały, że wpłaty przepadły?

Nie bezpośrednio. Większość transakcji, które trafiły do systemu przed timeout Cloudflare, była prawdopodobnie przetworzona asynchronicznie. Problem dotyczył UX (brak potwierdzenia) i duplikatów przy Retry Storm. Kluczowy warunek: poprawna implementacja Idempotency-Key zapobiega podwójnemu księgowaniu.

Dlaczego Multi-Cloud DNS jest ważne przy eventach tej skali?

Nawet najlepszy dostawca DNS może być przeciążony lub niedostępny podczas globalnych skoków ruchu. Rozproszenie rekordów między Cloudflare DNS a Amazon Route 53 jako fallback daje gwarancję, że awaria jednego dostawcy nie zatrzymuje całego ruchu. To standard bezpieczeństwa dla systemów o znaczeniu krytycznym.

Dlaczego licznik kwoty wyświetlał chwilami niższe wartości?

Prawdopodobny Thundering Herd na warstwie cache: gdy TTL wpisu wygasał w szczycie, miliony klientów jednocześnie odpytywały bazę. Rekomendowane rozwiązanie: Redis INCRBY (atomowe) + wzorzec stale-while-revalidate eliminujący jednoczesne cache misses.

Ile kosztowałoby odpowiednie przygotowanie infrastruktury?

Szacunkowo: load testy (k6 cloud) ~5–15 tys. PLN, pre-warming warstwy compute ~2–5 tys. PLN/event, static fallback < 50 PLN/miesiąc, War Room SRE on-duty: koszt wewnętrzny. Poniżej 25 tys. PLN łącznie – uzasadnione przy zbiórce rzędu 251 mln PLN.

Jak zapobiec Retry Storm w przyszłych zbiórkach?

Trzy środki jednocześnie: (1) Queue-First Architecture z kolejką komunikatów oddzielającą UX od bramki; (2) Idempotency-Key w każdym żądaniu płatności; (3) Virtual Waiting Room, który wpuszcza na stronę płatności tylko tylu użytkowników, ilu system obsłuży bez wzrostu latencji P99.