Szkolenie PHP – Skalowalność i asynchroniczność
Poziom
ZaawansowanyCzas
16h / 2 dniTermin
IndywidualnieCena
IndywidualnieSzkolenie PHP – Skalowalność i asynchroniczność
Warsztat uczy przenoszenia operacji poza request — z synchronicznego monolitu do asynchronicznego systemu opartego o kolejki wiadomości. Uczestnicy zaczynają z aplikacją, w której „wszystko dzieje się w requeście” (e-mail, PDF, aktualizacja stanów), i krok po kroku wprowadzają Symfony Messenger, workery i kolejki. Każdy etap rozwiązuje realny problem: wolny request → zduplikowane wiadomości → niespójna danych → różne wymagania odczytu i zapisu. Warsztat kończy się działającym systemem z asynchronicznym przetwarzaniem, idempotentnym kodem i CQRS lite — wzorcami, które działają zarówno w modularnym monolicie, jak i w architekturze mikroserwisowej.
Dla kogo jest to szkolenie?
Absolwentów ścieżki szkoleniowej PHP (Architektura), chcących wprowadzić asynchroniczność do swoich aplikacji-
Developerów PHP pracujących z aplikacjami, w których requesty trwają zbyt długo przez synchroniczne operacje
-
Programistów, którzy słyszeli o kolejkach i CQRS, ale nie wiedzą jak zacząć pragmatycznie
-
Zespołów planujących migrację z synchronicznej architektury na asynchroniczną
Czego nauczysz się na tym szkoleniu?
Symfony Messenger — konfiguracja, transporty, handlery, workery-
Przenoszenia operacji blokujących request do asynchronicznych kolejek
-
Projektowania idempotentnych handlerów — bezpieczna obsługa duplikatów wiadomości
-
Eventual consistency — zrozumienie i obsługa chwilowej niespójności danych
-
Procesów wieloetapowych (saga) — koordynacja zamówienie → płatność → wysyłka
-
CQRS lite — separacja modelu odczytu i zapisu bez event sourcing
-
Synchronizacji read modelu asynchronicznie przez Messenger
-
Retry, dead letter queue i obsługi błędów w procesach asynchronicznych
Wymagania
- PHP 8.3+: modularny monolit, bounded contexts, publiczne API modułów
- Zdarzenia domenowe — Symfony EventDispatcher
- Testy PHPUnit: unit i integracyjne
- Docker i Composer
Program szkolenia
Dzień 1
Etap 1: Symfony Messenger — kolejki wiadomości
- Problem: request trwa 5 sekund — dlaczego i co z tym zrobić?
- Symfony Messenger — konfiguracja, transport RabbitMQ (AMQP), message i handler
- Praktyka: wysyłka e-maila i generowanie PDF jako asynchroniczne handlery
- Worker — uruchamianie, monitorowanie, supervisor w Docker
- RabbitMQ management UI — podglądanie kolejek, wiadomości, stanu workerów
- Retry i dead letter queue — co gdy handler się wywali?
- Efekt: Operacje blokujące request są przeniesione do workerów; request jest szybki
Etap 2: Idempotentność
- Problem: worker przetwarza wiadomość dwa razy — klient dostaje dwa maile
- Dlaczego duplikaty się zdarzają — at-least-once delivery, network failures, worker restart
- Idempotent handler — projektowanie handlerów bezpiecznych przy wielokrotnym uruchomieniu
- Wzorce: idempotency key, deduplikacja, upsert zamiast insert
- Praktyka: zabezpieczenie handlerów z etapu 1 przed duplikatami
- Efekt: Uczestnicy rozumieją at-least-once delivery i potrafią pisać idempotentne handlery
Dzień 2
Etap 3: Eventual consistency
- Problem: zamówienie złożone, ale stan magazynowy jeszcze nie zaktualizowany
- Synchroniczne vs asynchroniczne — konsekwencje architektoniczne
- Eventual consistency — dane BĘDĄ spójne, ale nie natychmiast
- Eventy jako fakty vs komendy jako intencje
- Saga/Process Manager — koncepcja + demo koordynacji procesu zamówienie → płatność → wysyłka
- Kompensacja zamiast rollbacku — obsługa błędów w procesach asynchronicznych
- Efekt: Uczestnicy rozumieją trade-offy asynchroniczności i potrafią projektować procesy wieloetapowe
Etap 4: CQRS lite i podsumowanie
- Problem: listingi wymagają joinów przez 5 tabel, a zapis dotyka jednej — dlaczego traktujemy je tak samo?
- CQRS lite — separacja modelu odczytu i zapisu (bez event sourcing)
- Write model — agregaty, walidacja, reguły biznesowe
- Read model — zdenormalizowane projekcje zoptymalizowane pod odczyt
- Synchronizacja read modelu asynchronicznie przez Messenger (łączy wszystkie tematy warsztatu)
- Praktyka: listing zamówień jako read model aktualizowany asynchronicznie
- Kiedy NIE stosować CQRS — prosty CRUD nie potrzebuje separacji modeli
- Retrospektywa — przegląd ewolucji od synchronicznego monolitu do asynchronicznego systemu
- Efekt: Uczestnicy mają kompletny obraz: kolejki → idempotentność → eventual consistency → CQRS lite
