Active chapterCase study
Case study / 06
A production-ready microservices architecture with 5 NestJS services (API Gateway, Auth, Users, Products, Payments) communicating entirely through RabbitMQ events, each with its own PostgreSQL database, deployed on Kubernetes with full CI/CD.
01 / System behavior
A project-specific technical mechanism based on the recorded architecture and implementation context.
This project builds the complete microservices picture - not a toy demo, but a production-shaped system with real event-driven communication, database isolation, health checks, and CI/CD.
Five NestJS services run independently, each with its own Prisma schema, migrations, and PostgreSQL database. The API Gateway is the single entry point - it doesn't contain business logic, only routing, JWT authentication, rate limiting (100 req/min), and health aggregation. It proxies requests to downstream services and reports aggregate health: healthy (all up), degraded (some down), or unhealthy (all down).
03 / Architecture record
A structured reading of the architecture recorded with this project.
Five NestJS services in a Turborepo monorepo, each running on its own port:
• API Gateway (3000) - Routing, JWT validation, rate limiting, request aggregation, health check aggregation • Auth Service (3001) - Registration, login, JWT tokens, password reset, Passport.js strategies • User Service (3002) - Profiles, preferences, addresses; listens for auth.user.registered events • Product Service (3003) - Catalog, categories, inventory; publishes inventory.low_stock alerts • Payment Service (3004) - Orders, payments, refunds; maintains denormalized product cache from product events
All inter-service communication flows through a RabbitMQ topic exchange (microservices.events). Events follow the {service}.{entity}.{action} naming convention. Shared packages ensure publisher and consumer always agree on routing key strings.
Infrastructure: Docker Compose for local development (PostgreSQL, Redis, RabbitMQ, Adminer), Kubernetes manifests for production deployment with readiness/liveness probes.
Services communicate asynchronously via RabbitMQ with a topic exchange. When a user registers, the Auth Service publishes auth.user.registered - the User Service creates a profile, the Email Service sends a welcome email, the Analytics Service tracks the signup. The Auth Service has no idea who's listening. Event payloads follow a standardized format: eventType, data, timestamp, service, version. All messages are persistent JSON buffers with unique message IDs.
Each service's EventService implements connection resilience: if RabbitMQ is unavailable at startup, the service retries every 5 seconds. Services start and operate even if the message broker is temporarily down - they just can't publish events until the connection recovers.
Health checks are three levels deep: /health (full check with database connectivity), /health/ready (readiness probe), and /health/live (liveness probe). Kubernetes manifests reference these for pod management.
05 / Selected highlights
The decisions and workflows that carry the most explanatory weight.
06 / Supported metrics
TypeScript, NestJS, Prisma, PostgreSQL, RabbitMQ, Redis, Docker, Kubernetes, Turborepo, GitHub Actions, Fastify, Swagger/OpenAPI, Passport.js, JWT
View source repository