Fetch

// stack

// architecture

// overview

Six independently deployable services spanning Python/FastAPI and Node.js/TypeScript, behind an API gateway, each owning its own PostgreSQL database. Order placement runs as a choreographed saga over RabbitMQ with a transactional outbox on the way out and an inbox claim on the way in, so a broker outage cannot lose an order and a redelivery cannot double-charge a customer. Every service is traced end to end with hand-written OpenTelemetry instrumentation, exports metrics to Prometheus, and runs on Kubernetes with resource limits, horizontal autoscaling and Terraform environments for both a local kind cluster and AWS EKS. Almost every claim in the README was verified live against the running system — real orders placed, RabbitMQ and PostgreSQL deliberately stopped mid-flow, synthetic poison messages published — rather than inferred from the code.

// what was built

• ·Six independently deployable services behind an API gateway — auth, restaurants, orders, payments, driver matching, notifications — deliberately polyglot across Python/FastAPI and Node.js/TypeScript so the boundaries have to be real contracts, not shared code.
• ·The payments and driver-matching services are Python and FastAPI end to end: async handlers, Pydantic models on every boundary, aio-pika consumers, SQLAlchemy over their own PostgreSQL databases, and pytest suites — full participants in the saga, not sidecars bolted onto a Node system.
• ·Four of those services run as two processes from one codebase: an API that only serves HTTP and a worker that owns every piece of async work, so a slow consumer can never starve request handling and each half scales on its own.
• ·RS256-signed JWTs verified independently at each service boundary against auth-service’s public key, so no service has to call auth to authenticate a request.
• ·Order placement is a choreographed saga over a single RabbitMQ topic exchange — no orchestrator. The failure path is the interesting half: an unassignable order triggers a compensating refund and unwinds to CANCELLED instead of stranding a charge.
• ·Transactional outbox: an order and its outbox row commit in the same Postgres transaction, and a separate publisher process drains it. Verified by stopping RabbitMQ, placing an order (still 201), restarting, and watching the saga complete from the queued row.
• ·Transactional inbox keyed by publisher-assigned event id, with a RECEIVED → PROCESSING → PROCESSED/FAILED lifecycle, so a crash mid-handler leaves a queryable record rather than a vanished message.
• ·Delayed retry queues for transient failures and a diagnostics-carrying dead letter queue for poison messages — never silently dropped, never retried forever.
• ·Event schema versioning with version-aware parsers on both consumers, independently implemented in Python and TypeScript, plus JSON Schema contracts in a shared directory validated fail-fast on the producer and defensively on the consumer.
• ·Redis-backed sliding-window rate limiting at the gateway, implemented as a single atomic Lua script and failing open on a Redis outage — with a separate counter for fail-opens, because "clients are being throttled" and "throttling is not happening at all" are different operational facts.
• ·Circuit breaker plus hand-rolled retry with exponential backoff on the one synchronous inter-service hop, so a dead restaurant-service produces fast 503s instead of a self-inflicted retry storm.
• ·End-to-end OpenTelemetry tracing, deliberately without auto-instrumentation and hand-written twice — once against the Python SDK and once against the Node one — exporting to Jaeger; metrics to Prometheus; five Grafana dashboards and three alert rules, all provisioned as code.
• ·Kubernetes-native: Deployments, StatefulSets, resource requests and limits, Horizontal and Vertical Pod Autoscalers, host-based Ingress — plus a Terraform foundation covering both a local kind cluster and AWS EKS.