Case study backend PHP

System Rozproszony 3 Mikrousług

Trzy usługi PHP z osobnymi zależnościami, komunikacją HTTP, event flow przez RabbitMQ, health endpointami i granicą procesu workera.

Omów podobny problem Wróć do projektów

Case study

Zakres techniczny

Część repozytoriów jest prywatna do czasu zamknięcia prac. Zakres projektu, decyzje techniczne i scenariusze działania są opisane na stronie. Kod mogę omówić na rozmowie technicznej.

Problem

System rozproszony powinien pokazać realne granice usług, a nie tylko trzy katalogi w jednym repozytorium.
Najważniejsze ryzyka to zależność synchroniczna między order-service i user-service, brak jawnych kontraktów eventów oraz brak produkcyjnych mechanizmów retry, dead-letter i idempotencji konsumenta.

Decyzja techniczna

Osobne dependency graphy, API kontra worker, event asynchroniczny.
Order-service sprawdza użytkownika przez HTTP w user-service, dzięki czemu zależność synchroniczna jest widoczna i łatwa do omówienia bez warstwy gRPC albo OpenAPI.
Po utworzeniu zamówienia order-service publikuje order_created do RabbitMQ, a notification-service działa jako consumer kolejki zamiast klasycznego API HTTP.
Każda usługa ma osobne zależności Composer, Dockerfile i health boundary, co podkreśla niezależność procesów i dependency graphów.

Efekt

Lookup użytkownika, tworzenie zamówienia, consumer order_created.
Flow zamówienia: klient wysyła request do order-service, order-service pyta user-service, tworzy zamówienie i publikuje order_created.
Notification-service konsumuje wiadomość z kolejki RabbitMQ i wypisuje ją w logach kontenera.
Health endpointy usług, Docker Compose dla środowiska lokalnego, RabbitMQ Management UI i osobne dependency graphy Composer.

Stack

PHP / RabbitMQ / Docker / Microservices
docker compose up --build
healthcheck demo
order flow demo