Usługi aplikacyjne: SQS, SNS, EventBridge

Wyobraź sobie restaurację. Kelner przyjmuje zamówienia, ale zamiast biec prosto do kuchni z każdym, wrzuca karteczkę na półkę. Kucharz zabiera karteczki w swoim tempie. Nawet jeśli kelner przyjmie 50 zamówień na raz, kuchnia nie zostanie zablokowana. To właśnie robi kolejka wiadomości w świecie aplikacji.

W tej lekcji poznasz trzy kluczowe usługi, które pozwalają budować luźno powiązane (loosely coupled) systemy w AWS. To fundamentalna koncepcja, która pojawia się na egzaminie Cloud Practitioner.

Dlaczego „loosely coupled" to takie ważne?

W tradycyjnej architekturze (tightly coupled) aplikacja A woła bezpośrednio aplikację B. Jeśli B padnie, A też przestaje działać. To jak domino.

W architekturze loosely coupled, między A i B stoi pośrednik (kolejka, temat, event bus). Jeśli B padnie, wiadomości czekają w kolejce. Gdy B wróci, przetwarza je po kolei. Zero domina.

💡 Kluczowa zasada
Loose coupling = odporność na awarie + łatwiejsze skalowanie. Na egzaminie, gdy widzisz pytanie o „decoupling" lub „loosely coupled architecture", szukaj odpowiedzi z SQS, SNS lub EventBridge.

Amazon SQS (Simple Queue Service)

SQS to w pełni zarządzana kolejka wiadomości. Producent (sender) wrzuca wiadomości do kolejki, konsument (receiver) je stamtąd pobiera i przetwarza. To najstarsza usługa AWS (uruchomiona w 2004 roku, przed samym EC2!).

Jak działa SQS?

  1. Producent wysyła wiadomość do kolejki SQS
  2. Wiadomość czeka w kolejce (nawet do 14 dni)
  3. Konsument odpytuje (poll) kolejkę i pobiera wiadomość
  4. Konsument przetwarza wiadomość i usuwa ją z kolejki

Kluczowe: konsument sam pobiera wiadomości (pull model). SQS nie „pcha" wiadomości do konsumenta.

⚖️ SQS Standard vs SQS FIFO
CechaSQS StandardSQS FIFO
KolejnośćBest-effort (może się zmienić)Gwarantowana (First-In-First-Out)
PrzepustowośćPrawie nieograniczonaDo 3000 msg/s z batchingiem
DuplikatyMożliwe (at-least-once delivery)Exactly-once processing
ZastosowanieWiększość przypadkówPłatności, zamówienia, transakcje
Nazwa kolejkiDowolnaMusi kończyć się na .fifo
⚠️ Na egzaminie
Gdy pytanie wymaga gwarantowanej kolejności wiadomości lub exactly-once processing, odpowiedź to SQS FIFO. Gdy pytanie mówi o „high throughput" i kolejność nie jest krytyczna, to SQS Standard.

Dead Letter Queue (DLQ)

Co się dzieje, gdy wiadomość nie może zostać przetworzona? Np. ma błędny format albo konsument wielokrotnie próbuje ją przetworzyć i za każdym razem leci błąd?

Po określonej liczbie nieudanych prób (maxReceiveCount), wiadomość trafia do Dead Letter Queue. To osobna kolejka SQS, do której wędrują „problemowe" wiadomości. Dzięki temu nie blokują głównej kolejki i możesz je potem przeanalizować.

🏢 Scenariusz: Sklep internetowy
Sklep online przyjmuje zamówienia. Każde zamówienie trafia do kolejki SQS. Backend przetwarza je po kolei: sprawdza stan magazynowy, rezerwuje produkt, wysyła potwierdzenie. Jeśli w Black Friday wpadnie 10 000 zamówień na minutę, kolejka buforuje je. Backend przetwarza w swoim tempie. Żadne zamówienie się nie zgubi. Jeśli któreś zamówienie ma problem (np. nieistniejący produkt), po 3 próbach trafia do DLQ. Zespół sprawdza DLQ rano i ręcznie rozwiązuje problemy.

Amazon SNS (Simple Notification Service)

SNS działa na zasadzie pub/sub (publish/subscribe). Masz temat (topic), do którego publikujesz wiadomość. Każdy, kto subskrybuje ten temat, automatycznie ją otrzymuje. To jak newsletter: piszesz raz, a wiadomość leci do wszystkich subskrybentów.

Jak działa SNS?

  1. Tworzysz SNS Topic
  2. Subskrybenci zapisują się na topic (mogą to być: email, SMS, HTTP endpoint, SQS queue, Lambda function)
  3. Publisher wysyła wiadomość do topicu
  4. SNS push wiadomość do WSZYSTKICH subskrybentów jednocześnie

Kluczowa różnica: SNS to push model. Wiadomość jest aktywnie wysyłana do subskrybentów (w odróżnieniu od SQS, gdzie konsument sam pobiera).

💡 Analogia
SQS = skrzynka pocztowa (sam sprawdzasz, kiedy chcesz). SNS = kurier dzwoni do drzwi (dostajesz natychmiast, czy chcesz, czy nie).

Fan-out Pattern: SNS + SQS

To jeden z najpopularniejszych wzorców architektonicznych w AWS. Masz jedno zdarzenie (np. nowe zamówienie), ale chcesz, żeby przetworzyło je kilka różnych systemów: jeden wysyła email, drugi aktualizuje magazyn, trzeci generuje fakturę.

Jak to zrobić? Publikujesz wiadomość do SNS Topic, a topic ma kilka subskrybentów, z których każdy to osobna kolejka SQS. Każdy system ma swoją kolejkę i przetwarza wiadomość niezależnie.

Przykład: nowy użytkownik rejestruje się w aplikacji.

  1. Aplikacja publikuje zdarzenie „NewUserRegistered" do SNS Topic
  2. Subskrybent 1 (SQS → Lambda): wysyła email powitalny
  3. Subskrybent 2 (SQS → Lambda): tworzy domyślny profil w bazie
  4. Subskrybent 3 (SQS → Lambda): dodaje do listy newsletterowej
  5. Subskrybent 4 (SQS → Lambda): wysyła powiadomienie do zespołu sales

Każdy system działa niezależnie. Jeśli wysyłka emaila się opóźni, tworzenie profilu nie jest blokowane. To właśnie loose coupling w praktyce.

Amazon EventBridge

EventBridge to serverless event bus. Możesz go traktować jako „inteligentniejszą" wersję SNS. Zbiera zdarzenia z wielu źródeł (usługi AWS, Twoje aplikacje, partnerzy SaaS) i routuje je do odpowiednich celów na podstawie reguł.

Co wyróżnia EventBridge?

  • Routing oparty na regułach: możesz filtrować zdarzenia po zawartości (np. „wyślij alert tylko gdy zamówienie > 1000 zł")
  • Integracja z SaaS: gotowe integracje z Zendesk, Datadog, Shopify i wieloma innymi
  • Natywne zdarzenia AWS: każda zmiana w AWS (np. zmiana stanu EC2, upload do S3) generuje event w EventBridge
  • Schema Registry: automatycznie odkrywa strukturę zdarzeń
  • Archive & Replay: możesz archiwizować zdarzenia i odtwarzać je później
⚖️ SNS vs EventBridge
CechaAmazon SNSAmazon EventBridge
ModelProsty pub/subEvent bus z regułami routingu
FiltrowaniePodstawowe (atrybuty)Zaawansowane (content-based routing)
Integracje SaaSBrak natywnychWiele gotowych partnerów
UżyciePowiadomienia, fan-outEvent-driven architecture, automatyzacja
ZłożonośćProsty w użyciuWięcej możliwości, więcej konfiguracji
🏢 Scenariusz: Automatyzacja operacyjna
Firma chce automatycznie reagować na zdarzenia w swoim środowisku AWS. Konfigurują EventBridge rule: „gdy EC2 instance zmieni stan na stopped, wyślij powiadomienie na Slacka i uruchom Lambda, która sprawdzi, czy to planowane". Inna reguła: „gdy ktoś usunie security group, natychmiast utwórz ją ponownie i wyślij alert do zespołu security". To event-driven architecture w akcji: zero pollingu, natychmiastowa reakcja.
⚠️ Na egzaminie
Na egzaminie Cloud Practitioner nie musisz znać szczegółów konfiguracji EventBridge. Musisz wiedzieć, że to serverless event bus do budowania event-driven architectures. Gdy pytanie mówi o „reagowaniu na zdarzenia AWS" lub „automatyzacji na podstawie zmian w środowisku", EventBridge to dobra odpowiedź.
✅ Do zapamiętania z tej lekcji
SQS = kolejka wiadomości (pull model), buforuje wiadomości między systemami
SQS Standard: wysoka przepustowość, best-effort ordering. SQS FIFO: gwarantowana kolejność, exactly-once
Dead Letter Queue (DLQ): przechwytuje wiadomości, których nie udało się przetworzyć
SNS = pub/sub (push model), wiadomość leci do wszystkich subskrybentów naraz
Fan-out pattern = SNS Topic + wiele kolejek SQS jako subskrybenci
EventBridge = serverless event bus z content-based routing i integracjami SaaS
Wszystkie trzy usługi służą do loose coupling (decoupling) systemów
🧠 Podsumowanie
  • SQS to kolejka wiadomości: producent wrzuca, konsument pobiera w swoim tempie. Idealne do buforowania obciążenia
  • SQS Standard daje prawie nieograniczoną przepustowość, FIFO gwarantuje kolejność i exactly-once delivery
  • Dead Letter Queue wyłapuje wiadomości, które wielokrotnie nie mogły zostać przetworzone
  • SNS to pub/sub: publikujesz raz, wiadomość leci do wielu subskrybentów (email, SMS, SQS, Lambda, HTTP)
  • Fan-out pattern łączy SNS z wieloma kolejkami SQS, pozwalając wielu systemom reagować na jedno zdarzenie
  • EventBridge to serverless event bus z inteligentnym routingiem, integracjami SaaS i natywnym wsparciem zdarzeń AWS
  • Loose coupling (decoupling) to kluczowa koncepcja: systemy komunikują się przez pośrednika, nie bezpośrednio
🧪 Sprawdź się

Firma chce przetwarzać zamówienia asynchronicznie. System zamówień wysyła wiadomości, a system fulfillment przetwarza je w swoim tempie. Która usługa najlepiej pasuje?

A Amazon SNS
B Amazon SQS
C Amazon EventBridge
SQS to kolejka wiadomości idealna do asynchronicznego przetwarzania. Producent wrzuca wiadomości, konsument przetwarza je w swoim tempie. SNS nadaje się do fan-out (wiele odbiorców), EventBridge do event-driven routing. Tutaj mamy prosty scenariusz: jeden nadawca, jeden odbiorca, asynchronicznie.

Jaki wzorzec architektoniczny łączy SNS Topic z wieloma kolejkami SQS, aby jedno zdarzenie było przetwarzane przez wiele systemów?

A Dead Letter Queue pattern
B FIFO processing pattern
C Fan-out pattern
Fan-out pattern to publikowanie wiadomości do SNS Topic, który przekazuje ją do wielu kolejek SQS. Każdy system (subskrybent) przetwarza wiadomość niezależnie. To klasyczny wzorzec loose coupling w AWS.

Która usługa AWS jest serverless event bus z content-based routing i gotowymi integracjami z partnerami SaaS?

A Amazon EventBridge
B Amazon SNS
C Amazon SQS
EventBridge to serverless event bus z zaawansowanym content-based routing, natywną integracją z partnerami SaaS (Zendesk, Datadog itp.) i automatycznym zbieraniem zdarzeń z usług AWS. SNS to prosty pub/sub, SQS to kolejka wiadomości.