Kiedy technologia spotyka się ze sportowymi emocjami na żywo, nie ma miejsca na błędy czy powtórki. Wszystko musi działać tu i teraz. W poniedziałek, 13 kwietnia 2026 roku, podczas półfinałowego meczu siatkówki pomiędzy Projekt Warszawa a LUK Lublin, na trybunach zasiadło około 4 tysięcy kibiców.
Właśnie w takich warunkach zadebiutowała aplikacja konkursowa naszego klienta AP FLOTA - zajmującego się wynajmem długoterminowym i zarządzaniem flotą.
Mechanika zabawy była pozornie prosta: uczestnicy musieli jak najszybciej odpowiedzieć na 10 pytań. Haczyk polegał na tym, że konkurs trwał wyłącznie w trakcie meczu. Co więcej, spiker w hali zachęcał do udziału przy każdym nowym secie.
Jako osoba na co dzień łącząca biznes z technologią, od razu wiedziałem, że pod kątem technicznym ten projekt ma dwa kluczowe punkty zapalne: nagłe skoki obciążenia serwerów (tzw. piki ruchu) i podatność na manipulacje wynikami.
Problem nr 1: Piki ruchu, które kładą serwery
Typowa strona internetowa czy e-sklep notuje ruch, który rozkłada się stosunkowo równomiernie w ciągu dnia. W przypadku aplikacji eventowej sprawa wygląda zupełnie inaczej. Kiedy spiker przez mikrofon podaje adres strony, tysiące osób w tej samej sekundzie wyciąga telefony i próbuje załadować aplikację.
Z biznesowego punktu widzenia to moment prawdy. Jeśli system zawiedzie, a strona zwróci błąd, cała inwestycja w marketing i nagrody traci sens. Użytkownicy zapamiętają tylko frustrację.
Aby tego uniknąć, oparliśmy architekturę o platformę chmurową. Co to oznacza w praktyce? Zamiast ryzykować, że system w momencie nagłego skoku ruchu będzie potrzebował cennych ułamków sekund na „dobieranie” mocy, otrzymaliśmy od razu dostęp do potężnej puli zasobów. Aplikacja była w każdej chwili w pełni gotowa na uderzenie tysięcy żądań bez najmniejszego zadławienia.
Gdzie w tym wszystkim optymalizacja kosztów? W modelu rozliczeniowym. Chmura nalicza opłaty za faktyczne zużycie zasobów z dokładnością do sekundy. Nasz konkurs trwał 4 godziny. Dodatkowo gdy emocje w secie opadały, a ruch w aplikacji drastycznie malał, nasze koszty spadały niemal do zera. Osiągnęliśmy dzięki temu bezkompromisową szybkość reakcji dla każdego uczestnika i pełną kontrolę nad budżetem.
Ale samo wykupienie potężnej infrastruktury to za mało, żeby spać spokojnie. W takich projektach nadzieja to nie jest dobra strategia biznesowa. Dlatego przed „dniem zero” musieliśmy mieć twarde dowody, że architektura wytrzyma.
Przeprowadziliśmy rygorystyczne stress testy oparte na scenariuszach w narzędziu k6. Napisaliśmy skrypty, które symulowały sztuczny tłum tysięcy użytkowników rzucających się na aplikację w ułamku sekundy. Sprawdziliśmy granice wydajności w kontrolowanych warunkach. Dzięki temu, gdy spiker na hali faktycznie zaprosił kibiców do gry, mieliśmy maksymalną pewność, że wszystko zadziała bez zająknięcia.
Problem nr 2: Uczciwość mierzona w milisekundach
Drugim wyzwaniem była mechanika oceny. Skoro w konkursie liczy się czas odpowiedzi na 10 pytań, wyniki u najlepszych graczy potrafią różnić się o ułamki sekund. W takich sytuacjach zawsze znajdzie się ktoś, kto spróbuje oszukać system.
W internecie nietrudno o skrypty czy modyfikacje w przeglądarce, które pozwalają „zatrzymać czas” po stronie użytkownika, na spokojnie sprawdzić odpowiedź i wysłać ją z nierealnie dobrym wynikiem.
Dlatego wprowadziliśmy zaawansowane zabezpieczenia przed manipulacją. Nasz mechanizm nie ufał temu, co mówi telefon użytkownika. Zamiast tego precyzyjnie liczyliśmy czas po stronie serwera i porównywaliśmy go z czasem przeglądarki. Wszelkie odchylenia - świadczące o próbach ingerencji w kod czy pauzowania czasu - były od razu weryfikowane. Udało nam się zachować precyzję co do milisekundy, całkowicie odcinając drogę nieuczciwym praktykom.
Oczywiście wprowadziliśmy też automatyczne filtry, które blokowały możliwość ponownego wzięcia udziału w konkursie przez tę samą osobę.
Automatyzacja, która daje spokój na wydarzeniu
Kiedy wydarzenie trwa, nikt nie ma czasu na ręczne zatwierdzanie zgłoszeń czy zliczanie punktów w Excelu. Cały proces musiał dziać się automatycznie.
System sam w odpowiednim momencie otwierał bramki do przyjmowania zgłoszeń, błyskawicznie walidował poprawność odpowiedzi na 10 pytań, wyliczał czas z milisekundową dokładnością i układał ranking na żywo. Dzięki temu po zakończeniu konkursu wyłonienie zwycięzcy było formalnością, a organizatorzy mogli skupić się na wręczeniu nagrody.
Zobacz, jak to wyglądało w praktyce
https://youtube.com/shorts/iL6EZ2NI7yc
Najlepsza weryfikacja? Spokój klienta w trakcie eventu
Najlepszym potwierdzeniem tego, że odpowiednio zaplanowana architektura i rygorystyczne testy mają głęboki sens biznesowy, jest opinia samego klienta. Technologia ma przecież służyć temu, by organizatorzy nie musieli się o nią martwić, gdy na trybunach trwają sportowe emocje.
Michał Kwiecień, z którym współpracowaliśmy przy tym projekcie, tak podsumował nasze działania:
„Organizowanie konkursu na żywo dla tysięcy kibiców to zawsze duża presja i ryzyko wizerunkowe. Jeśli padnie serwer, cała akcja marketingowa traci sens. Zależało nam na partnerze, który nie tylko napisze aplikację, ale zagwarantuje, że wszystko bezbłędnie zadziała w tym jednym, krytycznym momencie pod ogromnym obciążeniem. Kodiwo dowiozło temat. Mieliśmy pełen spokój o zaplecze technologiczne i mogliśmy skupić się na uczestnikach oraz samym evencie.”
Podsumowanie:
Aplikacja dla AP Flota zebrała ostatecznie niemal 800 unikalnych, pomyślnie zweryfikowanych zgłoszeń w bardzo wąskim oknie czasowym. Niezawodność chmury pozwoliła na płynne przyjęcie ruchu rzędu kilku tysięcy osób, a zastosowane procedury bezpieczeństwa zagwarantowały sprawiedliwą wygraną (swoją drogą - wielkie gratulacje dla zwycięzcy!).
To case study doskonale pokazuje, że dobrze dobrana technologia nie polega na stawianiu największego i najdroższego serwera z możliwych. Polega na inteligentnym skalowaniu zasobów tam, gdzie pojawia się potrzeba, i przewidywaniu zachowań użytkowników, zanim staną się one problemem.
Planujesz akcję marketingową, kampanię lub event, który wygeneruje nagły, duży ruch? Z doświadczenia wiem, że warto wcześniej zrewidować architekturę takich rozwiązań, by nie stracić wizerunku z powodu błędu „503 Service Unavailable”. Jeśli chcesz mieć pewność, że Twoje zaplecze technologiczne to wytrzyma, odezwij się. Porozmawiamy o tym, jak sensownie zabezpieczyć Twój projekt.
