Jak wybrać kolejkę i zdarzenia dla sprzedaży internetowej: Redis, RabbitMQ, Amazon SQS czy Kafka?

Architektura zdarzeniowa w sprzedaży internetowej oznacza, że system reaguje na fakty biznesowe: zamówienie przyjęte, płatność pobrana, stan zarezerwowany, faktura zamówiona, wysyłka utworzona, zwrot przyjęty. Zdarzenie opisuje coś, co już się wydarzyło. Nie jest poleceniem w stylu "zrób fakturę teraz". Ta różnica pozwala budować odporne przepływy, a nie tylko odkładać wolne operacje na później.

W klasycznej finalizacji zamówienia jeden duży system często robi wszystko po kolei: zapisuje zamówienie, pyta system finansowo-magazynowy, generuje fakturę, wysyła e-mail, aktualizuje system obsługi klienta, rezerwuje magazyn i odświeża wyszukiwarkę. Jeden wolny element może zamrozić koszyk. Podejście zdarzeniowe oddziela decyzję zakupową od prac pobocznych: klient szybko dostaje jasny status, a reszta systemów nadrabia pracę przez kolejki i procesy w tle.

To nie jest magia bez kosztu. Praca w tle oznacza ponowne próby, możliwe duplikaty, wiadomości dostarczone w innej kolejności, kolejki błędów, monitorowanie działania i ręczne procedury naprawy. Dobry projekt nie zaczyna od pytania "które narzędzie jest najlepsze?", tylko od pytania "jakiej gwarancji potrzebuje ten konkretny proces?".

Najgorszy projekt zdarzeniowy wysyła wszystko w tło i udaje, że problem spójności zniknął. Finalizacja zamówienia musi jasno rozróżniać decyzje krytyczne od prac pobocznych. Autoryzacja płatności, walidacja ceny, rezerwacja stanu albo sprawdzenie limitu kredytowego mogą być częścią decyzji biznesowej. Faktura, e-mail, aktualizacja obsługi klienta, indeksowanie wyszukiwarki i część raportowania zwykle nie powinny blokować kupującego.

Dobry model zaczyna się od decyzji zakupowej: przyjmij koszyk, sprawdź warunki, zapisz intencję zamówienia, potwierdź płatność albo status oczekiwania, a dopiero potem wyślij informacje do reszty systemów. Jeżeli system finansowo-magazynowy jest źródłem prawdy dla stanu lub kredytu kupieckiego, trzeba jasno ustalić, czy proces zakupu czeka na ten system, używa lokalnego odczytu, czy przyjmuje zamówienie warunkowo z późniejszą weryfikacją.

W GMI często projektujemy to jako najwęższy produkcyjny wycinek: serwis zamówień w NestJS, PostgreSQL dla stanu transakcyjnego, kolejka dla prac poza ścieżką krytyczną, procesy w tle dla faktur, finansów, obsługi klienta i magazynu oraz panel operacyjny dla błędów. To jest architektura na szczyt sprzedaży, nie tylko "kolejka w kodzie".

AWS dokumentuje, że SQS Standard zapewnia dostarczenie co najmniej raz. W praktyce oznacza to, że wiadomość może przyjść więcej niż raz i czasem poza kolejnością. To nie jest wada do ukrycia, tylko zasada działania, którą musi zaakceptować aplikacja. Fakturowanie, synchronizacja z finansami i wysyłka e-maili muszą być odporne na ponowne przetworzenie tej samej informacji.

Odporność na duplikaty oznacza, że to samo zdarzenie przetworzone dwa razy nie tworzy dwóch faktur, dwóch płatności, dwóch wysyłek ani dwóch sprzecznych wiadomości do klienta. W praktyce trzymasz identyfikator zdarzenia, identyfikator zamówienia, wersję, klucz bezpiecznego ponowienia i status przetworzenia. Operacja może zostać powtórzona bez zmiany skutku biznesowego.

Jeżeli kolejność jest krytyczna, projektuj ją dla konkretnego obiektu biznesowego: jednego zamówienia, klienta albo produktu w danej lokalizacji. SQS FIFO używa grup wiadomości, a Kafka utrzymuje porządek w ramach partycji dla tego samego klucza. Globalny porządek całego sklepu zwykle nie jest potrzebny i tylko podnosi koszt.

Każdy system oparty na zdarzeniach musi odpowiedzieć na pytanie: co robimy, gdy proces w tle nie potrafi przetworzyć wiadomości? Ponawianie bez limitu może zatkać kolejkę. Brak ponawiania gubi chwilowe awarie finansów albo magazynu. Zbyt niski limit przenosi normalne opóźnienia do kolejki błędów. Zbyt wysoki limit ukrywa błąd przez godziny.

Kolejka błędów w Amazon SQS pozwala odłożyć wiadomości, których nie udało się przetworzyć, sprawdzić przyczynę i uruchomić je ponownie. AWS zaleca ustawić `maxReceiveCount` wystarczająco wysoko, żeby system miał szansę przetrwać błędy przejściowe. RabbitMQ ma osobne ścieżki dla błędnych wiadomości i potwierdzenia odbioru: kolejka usuwa wiadomość dopiero po potwierdzeniu, że proces ją obsłużył.

W praktyce kolejka błędów nie jest koszem. To lista zadań dla systemu i zespołu. Musi mieć powiadomienie alarmowe, właściciela, procedurę reakcji, metryki wieku wiadomości i jasną decyzję: ponowić, poprawić ręcznie, anulować, zwrócić pieniądze albo skontaktować się z klientem. Bez tego architektura zdarzeniowa tylko przenosi awarie z koszyka na zaplecze operacyjne.

W sprzedaży internetowej zdarzenie jest częścią umowy między zespołami. `order.accepted.v1` powinno mieć właściciela, opis pól, wersję, pola wymagane, znaczenie czasu i zasady zgodności wstecznej. Jeżeli eksport do systemu finansowego zakłada, że `customerVatId` zawsze istnieje, a proces zakupu przestaje je wysyłać, awaria pojawi się daleko od miejsca zmiany.

Nie każde zdarzenie powinno zawierać pełne dane. Czasem wystarczy identyfikator i proces w tle dociąga stan zamówienia z interfejsu systemowego. Czasem potrzebujesz niezmiennego zestawu danych, bo cena, podatki i adres wysyłki muszą odzwierciedlać moment zakupu. To jest decyzja domenowa, nie techniczna preferencja.

Dobre zdarzenia nie są nazwane od implementacji. `sendEmail` to polecenie dla konkretnego procesu. `orderPaid`, `invoiceRequested`, `shipmentCreated`, `returnReceived` to fakty biznesowe. To odróżnia architekturę zdarzeniową od rozproszonego chaosu, w którym każdy system rozumie zamówienie inaczej.

Nie wystarczy wiedzieć, że kolejka istnieje. W sprzedaży internetowej musisz wiedzieć, ile zamówień czeka na system finansowo-magazynowy, ile faktur jest w kolejce błędów, jak stara jest najstarsza wiadomość, jaki procent ponownych prób kończy się sukcesem i czy zaległość rośnie szybciej niż tempo pracy systemu.

Najważniejsze mierniki są biznesowe: płatność pobrana, ale zamówienie niewyeksportowane; zamówienie przyjęte, ale faktura brakująca; wysyłka utworzona, ale klient niepowiadomiony; zwrot przyjęty, ale zwrot pieniędzy nierozpoczęty. Techniczne wykresy kolejki pomagają, ale same nie powiedzą dyrektorowi finansowemu, ile pieniędzy utknęło między systemami.

W GMI projektujemy panel operacyjny razem z kolejkami. Obsługa klienta i zespół operacyjny muszą widzieć status zamówienia, ostatnie zdarzenie, liczbę ponownych prób, powód błędu i bezpieczne akcje: ponów, pomiń, popraw ręcznie, skontaktuj się z klientem. Wtedy architektura zdarzeniowa przestaje być technologią dla technologii i staje się procesem pracy.

Wydzielenie bezpiecznej ścieżki zdarzeniowej dla procesu zakupu, finansów, danych produktowych, magazynu, faktur i e-maili zwykle zaczyna się od 160 000-300 000 PLN, zależnie od liczby połączeń i jakości obecnego systemu. Sama kolejka jest tania. Koszt tworzą: model biznesowy, odporność na duplikaty, widoczność działania systemu, ponowne próby, kolejka błędów, testy i model naprawy błędów.

Najmniejszy sensowny zakres to: mapa przepływów, opis zdarzenia, kolejka, kilka procesów w tle, kolejka błędów, monitorowanie, magazyn kluczy do bezpiecznych ponowień i scenariusze regresji finalizacji zamówienia. Większe zakresy obejmują serwis zamówień, dziennik zmian, dłuższy przepływ transakcyjny przez kilka systemów, synchronizację z finansami, magazynem i platformami handlowymi, wiele krajów, Kafkę jako platformę danych oraz migrację historycznych zdarzeń.

GMI daje wstępną estymację w 48 godzin, ale stałą cenę dopiero po rozpoznaniu biznesu, projektu i technologii. W tym etapie ustalamy, które działania mogą odbywać się w tle, które muszą zostać wykonane od razu, co wymaga zachowania kolejności w ramach jednego zamówienia, klienta albo produktu, kto obsługuje kolejkę błędów i jakie metryki pokażą, że sklep jest gotowy na szczyt sprzedaży.

Zaczynamy od rozpoznania biznesu, projektu i technologii oraz mapy procesu: proces zakupu, płatność, rezerwacja stanu, system finansowo-magazynowy, dane produktowe, magazyn, faktura, wiadomość e-mail, obsługa klienta, wyszukiwarka, powiadomienia mobilne i raportowanie. Potem rozdzielamy ścieżkę krytyczną od prac, które mogą wykonać się w tle, i wybieramy transport pod konkretne gwarancje, nie pod modę.

Technicznie najczęściej łączymy NestJS, PostgreSQL, Redis, RabbitMQ, Amazon SQS, czasem Kafkę, Next.js, React Native i MedusaJS. W sprzedaży internetowej ważna jest nie tylko kolejka, ale cały model: transakcyjny dziennik zmian, odporność na duplikaty, ponowne próby, kolejka błędów, dziennik audytu, panel operacyjny i testy regresji finalizacji zamówienia.

Biznesowo klient dostaje własność kodu źródłowego, brak uzależnienia od dostawcy, stałą cenę po rozpoznaniu zakresu i utrzymanie po starcie. To jest szczególnie ważne, bo sprzedaż internetowa oparta na zdarzeniach żyje długo po wdrożeniu: nowe kanały sprzedaży, połączenia z systemem finansowo-magazynowym, platformy handlowe i aplikacje mobilne będą dopisywać kolejne zdarzenia.