Details

product / shipped

Incubator Manager

A microservices management platform for a business incubator: companies, users, contracts, payments, spaces, bookings, inventory, support tickets, documents, and dashboards behind one Nginx gateway.

Live 3D architecture

The scene beside this panel is this system's architecture. Drag to rotate, scroll panel to read on.

Problem

Incubators run on interlocking workflows — company lifecycles, space contracts, recurring payments, room and equipment bookings, support tickets, and document trails — serving three different audiences: staff, incubated companies, and the public. Off-the-shelf tools either merge everything into one over-privileged surface or scatter it across systems that disagree with each other.

Contribution

Designed and built the full platform as a strict microservices monorepo: ten Django REST services (auth, companies, contracts, finance, spaces, bookings, inventory, tickets, dashboards, documents), an Nginx gateway with centralized JWT validation, a RabbitMQ event backbone, and a Next.js 14 frontend with role-guarded staff and client route groups plus a public booking-request flow.

Architecture

Every business context is a separately deployable Django service owning its own PostgreSQL schema; cross-service references are UUIDs, never shared ORM models. All traffic enters through the Nginx gateway, which validates JWTs via auth_request against the auth service and forwards trusted identity headers (user, role, company) downstream. Synchronous REST handles request/response work; RabbitMQ domain events (company.created, contract.activated, booking.approved, payment.recorded…) update projections and dashboards with idempotent consumers. Documents live in MinIO; Redis backs token revocation and rate limiting; cron sidecars replace Celery.

Technical decisions

One bounded context per Django service with a private database schema — no shared models
Nginx auth_request centralizes JWT validation; services trust gateway-injected identity headers only inside the network boundary
RabbitMQ topic exchange with a shared event envelope and idempotent consumers keyed on event_id
Read-model projections for dashboards instead of cross-service KPI queries
Docker Compose as the production shape, Tilt for scoped live-reload development
Deterministic seed data and a host-side quality gate covering all ten services and the frontend

Tradeoffs

Strict service boundaries over monolith convenience — more moving parts, cleaner ownership
Eventual consistency for projections in exchange for service autonomy
Cron sidecars instead of Celery to keep the operational surface small
Compose-based deployment over Kubernetes to match the incubator's actual scale

Outcome

The full production-shaped stack boots locally with a single make command, seeds deterministic demo data, and passes an end-to-end gate: Ruff, ESLint, TypeScript, Vitest, per-service pytest with migration checks, and Playwright smoke tests through the real gateway. The architecture write-up, event catalogue, deployment runbook, and final report ship in the repo's docs.

Stack and domains

  • Python
  • Django
  • Django REST Framework
  • PostgreSQL
  • RabbitMQ
  • Redis
  • MinIO
  • Next.js
  • TypeScript
  • Ant Design
  • Nginx
  • Docker Compose
  • Tilt