Event-driven delivery platform
OrderFlow
A food-delivery backend where order state moves through independent services over Kafka, with synchronous HTTP kept at the edge.Owns order state, idempotent placement, and the transactional outbox.
The constraint.
Distributed order flows fail in ways monoliths do not — partial failures, duplicate events, lost messages between database commit and message publish.
How it is shaped.
Spring Cloud Gateway fronts the Spring Boot services. Order Service writes state and an outbox record in one transaction; Kafka carries payment, order, delivery, and location events. Each stateful service owns its PostgreSQL data.
Decisions made explicit.
- Transactional outbox for atomic order events
- Idempotency keys and consumer deduplication
- Saga choreography with compensating transactions
- Redis token-bucket limits, menu cache, and driver GEO search
Where it can break.
Failed payments compensate the order to CANCELLED; outbox publishing retries before routing to a dead-letter queue. Consumers are idempotent so replays are safe.
What I learned.
Reliability comes from explicit state transitions and replay-safe boundaries, not from assuming every dependency is available.