Skip to main content
PET_01 / Team project

Food Delivery Service
Event raceMay 2026

My roleUser Service, Nuxt frontend, Kubernetes deployment, fixing event consumers in the Delivery Service
TimelineMay 2026, university trimester
Delivered4 microservices, 34 gRPC endpoints, a DigitalOcean cluster
crisis_alertProblem

The payment event arrived before the order existed

The Order Service publishes order.created and order.paid to NATS JetStream. The Delivery Service creates a delivery on the first and assigns a driver on the second. Once it ran in two pods, order.paid was sometimes handled before order.created. The handler found no delivery, treated the message as invalid and dropped it for good. The order stayed paid, and no driver ever got it.

34
gRPC endpoints
8
User Service methods
2–6
API Gateway pods (HPA)
Stack[SYSTEM_ARCHITECTURE]

Go microservices and infrastructure as code

Services talk over gRPC, async events go through NATS JetStream. Each service follows Clean Architecture and owns its PostgreSQL database. A two-node DOKS cluster is provisioned with Terraform, and a Locust scenario covers load testing.

  • Go
  • gRPC
  • NATS JetStream
  • PostgreSQL
  • Redis
  • Nuxt
  • Kubernetes
  • Terraform
codedelivery-service/internal/nats/client.go
// Term = don't redeliver; Nak = retry.
// ErrNotFound is retried: order.paid can arrive
// before order.created is processed.
if errors.Is(err, usecase.ErrInvalidDelivery) {
    _ = msg.Term()
} else {
    _ = msg.Nak()
}
commit 02acc4f
Decisions

5 commits

What I would do differently

Event order is not guaranteed once there is more than one consumer. I only found the race once the service ran in two pods. Next time I would make handlers idempotent and model order states explicitly from the start.