PHP backend case study

System Rozproszony 3 Mikrousług

Three PHP services with separate dependencies, HTTP communication, RabbitMQ event flow, health endpoints, and worker process boundaries.

Discuss a similar problem Back to projects

Case study

Technical scope

Some repositories are private until the work is closed. Project scope, technical decisions, and operating scenarios are described on the page. I can discuss the code during a technical conversation.

Problem

A distributed-system demo needs to show real service boundaries rather than only three folders inside one repository.
The main risks are the synchronous dependency between order-service and user-service, missing explicit event contracts, and missing production-grade retry, dead-letter, and consumer-idempotency mechanisms.

Technical decision

Separate dependency graphs, API versus worker process, async event.
Order-service checks the user through HTTP against user-service, making the synchronous dependency explicit without adding gRPC or OpenAPI tooling.
After creating an order, order-service publishes order_created to RabbitMQ, while notification-service runs as a queue consumer instead of a classic HTTP API.
Each service has separate Composer dependencies, a Dockerfile, and a health boundary, emphasizing independent processes and dependency graphs.

Result

User lookup, order creation, order_created consumer.
Order flow: the client calls order-service, order-service queries user-service, creates the order, and publishes order_created.
Notification-service consumes the RabbitMQ message and writes it to container logs.
Service health endpoints, Docker Compose local environment, RabbitMQ Management UI, and separate Composer dependency graphs.

Stack

PHP / RabbitMQ / Docker / Microservices
docker compose up --build
curl health endpoint
post order demo