Studia przypadków / Aplikacja Live Sports dla pasażerówStudium · 10 min czytania · maj 2026
Studium · Przypadek 02 // Rozrywka pokładowa × Live Sports

Live Sports Ticker.

Jak prosty moduł dla jednego turnieju rozwinął się w platformę sportową na pokładzie — zaprojektowaną z myślą o niskiej przepustowości i ograniczonych możliwościach testowania.

Klient
Dostawca rozrywki pokładowej
Specjalizacja
Rozrywka pokładowa · Web · Live Sports
Rok
2024
Produkt
Live Sports Ticker
Stack
Next.js · Azure · Umbraco · Terraform
Status
Rozszerzona po Euro 2024
Relacje z meczów <em>na żywo</em>
Live Sports · EURO 2024

Relacje z meczów na żywo

Dostarczaj wyniki na żywo, statystyki meczów, komentarze, składy, kartki i kluczowe momenty poprzez lekki interfejs dla pasażerów, zaprojektowane z myślą o ograniczonej przepustowości, wcześniej zatwierdzonych adresach URL i wdrożeniu produkcyjnym, które musi zadziałać za pierwszym razem.

[ PLANSZA 01 — Live Sports · architektura API o niskiej przepustowości z listą dozwolonych adresów URL]
Proste zlecenie produktowe dla pasażerów przełożone na niezawodną aplikację sportową, w której liczyło się każde żądanie, testy na żywo były niedostępne, a architektura musiała od pierwszego dnia uwzględniać ograniczenia łączności.
§ 01 — Kontekst

Cel był prosty. Warunki — dużo mniej.

Założenie było proste: pasażer śledzi Euro 2024 na pokładzie. Na pokładzie samolotu ciężka aplikacja webowa nie wchodziła w grę. Oznaczało wyniki na żywo, statystyki meczów, komentarze, składy, kartki i kluczowe momenty dostarczane przez połączenie, w którym przepustowość mogła spaść poniżej 1 Mb/s, a każde zapytanie miało wymierny koszt.

Prawdziwe wyzwanie leżało w ograniczeniach technicznych. Adresy URL musiały być wcześniej dodane do listy dozwolonych, aplikacji nie dało się przetestować na żywo na pokładzie przed startem, a pierwsze wydanie produkcyjne musiało zadziałać od razu. To właśnie te ograniczenia wyznaczyły architekturę produktu.

§ 02 — Podejście

Projektowanie zaczęliśmy od realiów samolotu.

Zanim zaprojektowaliśmy interfejs, określiliśmy ograniczenia: wolną i kosztowną łączność, stałą listę dozwolonych adresów URL, brak możliwości iterowania na żywo w samolocie, wysokie opóźnienia oraz zasadę, że liczy się każdy kilobajt. Te ograniczenia wpłynęły zarówno na system techniczny, jak i UX.

Dostawcę danych sportowych wybraliśmy pod kątem małego rozmiaru odpowiedzi z API oraz szybkich aktualizacji. Pierwsze wydanie utrzymaliśmy bez zbędnych zależności od CMS, a interfejs pasażera zaprojektowaliśmy z myślą o czytelności, małej liczbie interakcji i odporności na niestabilne warunki sieciowe. Lekką analitykę dodaliśmy od początku, żeby mierzyć użycie bez konkurowania o transfer z danymi sportowymi na żywo.

● Plansza 02 — Liczby
50 tys.+
pasażerów
korzystało z aplikacji w początkowej fazie
1 mln+
interakcji
zarejestrowanych podczas wdrożenia na turniej
<1 Mb/s
kontekst przepustowości
typowe dla ograniczonej łączności pokładowej
sekundy
opóźnienie aktualizacji
dla aktualizacji zdarzeń przy ograniczonej przepustowości
§ 03 — System

Lekka aplikacja od pierwszego wydania.

Pierwszym wydaniem była aplikacja Next.js uruchamiana w kontenerze, hostowana na Azure i zaprojektowana specjalnie pod warunki pokładowe. Nie miała odtwarzać pełnego portalu sportowego. Miała dostarczać najbardziej przydatne informacje o meczu na żywo, przy przewidywalnym zachowaniu sieci, stałych endpointach i jak najmniejszym transferze danych.

Aby zmniejszyć ryzyko wdrożenia, stworzyliśmy symulowane środowisko testowe odtwarzające kluczowe ograniczenia pokładowe: limitowanie łącza, ograniczenia adresów URL, zachowanie aplikacji podczas inicjalizacji i brak możliwości iterowania na żywo w kabinie. To środowisko stało się miejscem końcowej weryfikacji przed wdrożeniem.

Po Euro 2024 system rozwinął się z funkcji przygotowanej pod jeden turniej w szerszą platformę sportową. Objął kolejne rozgrywki piłkarskie, ligi kobiece i męskie, sporty zimowe oraz wydarzenia związane z Zimowymi Igrzyskami Olimpijskimi.

§ 04 — Ewolucja

Platforma rozwijała się, ale nie traciła swojej podstawowej zasady.

Gdy produkt zaczął być używany szerzej, analityka stała się narzędziem produktowym, a nie tylko dodatkiem do raportowania. Pokazywała, z jakich typów treści pasażerowie faktycznie korzystają, jak angażują się w widoki na żywo w porównaniu ze statycznymi i gdzie można uprościć produkt bez szkody dla UX.

Prace nad wydajnością trwały także po starcie. Wybrane zewnętrzne skrypty przenieśliśmy do własnego środowiska hostingowego, aby zmniejszyć liczbę żądań, poprawić przewidywalność ładowania i dać zespołowi kontrolę nad rozmiarem zasobów oraz wersjonowaniem. Później dodaliśmy Umbraco w trybie headless, z wielopoziomowym cachowaniem, tak aby możliwość edycji treści nie obciążała aplikacji.

§ 05 — Wdrożenia

Szybkość wdrożeń stała się częścią produktu.

Rezultatem był produkt sportowy, który mógł się dalej rozwijać, nie zamieniając się w ciężką aplikację pełną zależności. To było kluczowe, bo właśnie taki typ rozwiązania nie sprawdziłby się w ograniczeniach pokładowych, dla których produkt został zaprojektowany.

● Plansza 03 — Cytat
„Na początku wyglądało to jak prosta aplikacja sportowa na żywo. W rzeczywistości trzeba było zbudować niezawodny produkt dla warunków pokładowych, gdzie lista dozwolonych adresów jest stała, łączność ograniczona, a każdy kilobajt ma znaczenie.”
— zespół projektowy Coffee Mug · opracowano maj 2026
● Plansza 04 — Diagram systemu
[ DANE SPORTOWE → POZYSKIWANIE → API → APLIKACJA LIVE SPORTS ][ DANE SPORTOWE → POZYSKIWANIE → API → APLIKACJA LIVE SPORTS ]
Ograniczony proces wdrażania: efektywne dane sportowe, kontrolowane endpointy, usługi z cachem, lekki klient i analityka ograniczona do niezbędnych danych.
● Plansza 05 — Zestawienie wyników

Co się zmieniło, w pięciu punktach.

01 · Początkowy zakres
funkcja Euro 2024 → platforma sportowa
rozszerzona po walidacji podczas turnieju
02 · Użycie
50 000+ użytkowników
podczas początkowej fazy wdrożenia
03 · Zarejestrowane zaangażowanie
1 mln+ interakcji
zebrane za pomocą lekkiej analityki
04 · Aktualizacje
kilkusekundowe opóźnienie zdarzeń
przy ograniczonej przepustowości pokładowej
05 · Model operacyjny
zmiany ręczne → CMS + CI/CD
Umbraco headless, Terraform, zautomatyzowane procesy
● Metryka

Zakres i technologia.

Aplikacja Live Sports dla pasażerów zaczęła się od jednego turnieju, a przekształciła się w szerszą platformę sportową zaprojektowaną pod ograniczoną łączność w samolocie. System łączy lekką aplikację dla pasażerów, kontrolowane dostarczanie danych, niestandardową analitykę, zarządzanie treścią w modelu headless i odtwarzalną infrastrukturę chmurową.

Specjalizacja
Chmura · Web · Na pokładzie
Pokładowa aplikacja sportowa
Aplikacja
Next.js
Aplikacja dla pasażerów uruchamiana w kontenerze
Platforma
Azure
Hosting i kontrolowane dostarczanie
Operacje
Umbraco · Terraform · CI/CD
Treści w modelu headless, infrastruktura, wdrożenia
Typografia
Newsreader & DM Sans
Opracowano maj 2026
● Na koniec

Pokładowy produkt, który musi zadziałać za pierwszym razem?

Warto zaangażować nas, zanim lista dozwolonych adresów zostanie zatwierdzona. Pomożemy zaprojektować aplikacje najpierw wokół realnych ograniczeń — niskiej przepustowości, wysokich opóźnień, ograniczonych adresów URL i stanu w pamięci podręcznej.