Async vs Sync

Async vs Sync: Kiedy warto używać asynchroniczności?

Czy zastanawiałeś się, dlaczego niektóre aplikacje działają płynnie, a inne każą czekać na każdą operację? Klucz może tkwić w sposobie przetwarzania danych – synchronicznym lub asynchronicznym.

W tym artykule pokażę Ci:

Na czym polega różnica między synchronicznością a asynchronicznością?
Jakie konkretne problemy rozwiązuje podejście asynchroniczne?
Kiedy warto stosować które podejście?
Jak wykorzystać kolejki do zwiększenia skalowalności i niezawodności?
Jak radzić sobie z typowymi wyzwaniami?

konkrety, przykłady i dobre praktyki.

Synchroniczność vs Asynchroniczność – Przykład z życia

Wyobraź sobie, że podczas gotowania masz do wykonania 3 rzeczy:

Ugotować ryż (15 minut),
Usmażyć warzywa i mięso (10 minut),
Przygotować sos (5 minut).

Jak wyglądało by gotowanie w stylu synchronicznym:

Wstawiasz ryż na ogień i czekasz aż się ugotuje – 15 minut.
Gdy ryż jest gotowy, zaczynasz smażysz warzywa i mięso – 10 minut.
Na koniec przygotowujesz sos – 5 minut.
Łączysz składniki i po 30 minutach masz już obiad

Wydaję się to dość nie efektywne, nie sądzisz?

W prawdziwym życiu przygotowałbyś to prawdopodobnie w stylu asynchronicznym:

Wstawiasz ryż na ogień i ustawiasz timer – 15 minut, ale nie czekasz aż ryż się ugotuje.
W międzyczasie smażysz warzywa i mięso – 10 minut.
W między czasie przygotowujesz sos – 5 minut.
Łączysz wszystkie składniki i po 15 minutach masz gotowy obiad.

Na tym prostym przykładzie zaprezentowałem jak asynchroniczność pozwala efektywnie wykorzystywać czas. W systemach IT to oznacza, że aplikacja nie „siedzi bezczynnie”, czekając na zakończenie jednej operacji – tylko wykonuje inne zadania w tle.

Przykład w IT: System HR przetwarzający CV

Załóżmy, że firma codziennie przetwarza tysiące CV. Każdy plik przechodzi przez:

Walidację danych (imię, nazwisko, doświadczenie itp.).
Analizę treści (np. wyszukiwanie słów kluczowych).
Konwersję do jednolitego formatu.
Zapis do bazy.

Jak wyglądało to w praktyce?

W jednym z projektów, w którym uczestniczyłem, użytkownicy wgrywali paczki tysięcy plików na raz. System działał synchronicznie, więc trzeba było czekać, aż całość zostanie przetworzona.

Jeśli po drodze padł serwer albo użytkownik odświeżył stronę – cały proces trzeba było zaczynać od nowa.

Problemy synchronicznego podejścia:

Długie oczekiwanie użytkownika.
Brak możliwości przerwania procesu bez utraty danych.
System staje się niewydolny przy dużej liczbie plików.
Brak odporności na błędy: Jeśli jedno z CV spowoduje błąd, cały proces może się zatrzymać, zamiast pominąć uszkodzone pliki i kontynuować.
Awaria serwera lub brak pamięci: Jeśli serwer ulegnie awarii lub skończy się pamięć RAM, cały proces może zostać przerwany, powodując utratę części lub całości przetwarzanych danych.

Rozwiązanie: Asynchroniczne przetwarzanie z użyciem kolejki
Zamiast wykonywać wszystko na raz i blokować użytkownika, możemy:

Zapisać pliki – np. na S3
Wysłać informację o pliku do kolejki (np. Kafka, RabbitMQ, SQS),
Pozwolić użytkownikowi działać dalej – bez oczekiwania,
Przetwarzać pliki w tle przez workery, które działają niezależnie
Poinformować użytkownika, gdy operacja się zakończy.

Jak działa kolejka w systemie asynchronicznym?

Wyobraź sobie kolejkę w restauracji fast food:

Składasz zamówienie – kuchnia je otrzymuje (kolejka),
Kuchnia zaczyna realizację – każdy kucharz (worker) bierze jedno zamówienie,
Dostajesz powiadomienie, gdy wszystko jest gotowe.

W systemie IT wygląda to podobnie:

Użytkownik wysyła CV – trafia ono do kolejki,
Worker odbiera CV i je przetwarza,
System powiadamia użytkownika o zakończeniu.

Korzyści:

Brak blokowania aplikacji,
Obsługa setek tysięcy operacji,
Odporność na awarie – nawet jeśli coś padnie, wiadomości w kolejce czekają na przetworzenie.

Trade-offy – Kiedy znane firmy stosują podejście synchroniczne lub asynchroniczne?

Uber – asynchroniczność jako standard skalowania

Uber obsługuje miliony użytkowników równocześnie – kierowców i pasażerów. Większość ich operacji, takich jak:

Wysyłanie żądania przejazdu,
Matching z kierowcą,
Powiadomienia push o lokalizacji,

odbywa się asynchronicznie. Użytkownik nie musi czekać, aż system dopasuje kierowcę – backend wysyła mu informację, gdy to się wydarzy. Wszystko działa przez kolejki zdarzeń i event-driven architecture.

„Klikasz: zamów przejazd. Aplikacja natychmiast mówi: 'szukamy kierowcy’. Nie musisz czekać na zakończenie procesu – działa to w tle.”

Netflix – miks podejść

Netflix wykorzystuje asynchroniczność w ogromnej skali:

Pobieranie rekomendacji,
Personalizacja treści,
Zbieranie statystyk oglądalności,

ale np. logowanie użytkownika lub płatność odbywają się synchronicznie – bo ważna jest spójność i natychmiastowa odpowiedź.

„Logowanie użytkownika? Ma być albo odrzucone, albo zatwierdzone – tu nie ma miejsca na kolejki.”

Airbnb – zależności i priorytety

Airbnb stosuje synchroniczność przy rezerwacjach (aby uniknąć podwójnej rezerwacji jednego mieszkania), a asynchroniczność przy:

Wysyłaniu maili,
Weryfikacji tożsamości,
Generowaniu raportów.

Zasada praktyczna: Kiedy synchronicznie, kiedy asynchronicznie?

Wybierz synchroniczność, gdy:

Użytkownik musi mieć natychmiastowy feedback,
Operacja ma wpływ na inne dane (transakcyjność),
Błąd nie może być tolerowany ani opóźniony (np. logowanie użytkownika).

Wybierz asynchroniczność, gdy:

Operacja może zająć więcej czasu, ale nie musi blokować użytkownika,
System musi być odporny na przeciążenie,
Można przetwarzać dane poza głównym flow (np. analiza, rekomendacje, wysyłka powiadomień).

Podsumowanie

Asynchroniczność i synchroniczność to nie tylko wybór techniczny – to decyzja architektoniczna, która wpływa na doświadczenie użytkownika, odporność systemu i jego zdolność do skalowania.

Nie chodzi o to, by zawsze stosować jedno lub drugie – chodzi o świadome podejście. Tam, gdzie liczy się szybkość reakcji i skalowalność – jak w Uberze, Netflixie czy Airbnb – asynchroniczność jest fundamentem. Tam, gdzie ważna jest spójność i natychmiastowa walidacja – synchroniczność wciąż ma swoje miejsce.