Multi-Tenant Event Management SaaS

Why this work matters

The Product Challenge

The platform needed to serve multiple event businesses from one product while still giving each tenant its own branded marketing layer, frontend experience, backend workflows and SSL-secured domain setup.

The difficult part was not only feature delivery. The architecture had to support tenant isolation, payments, environment separation and production operations without making every tenant a separate deployment.

My Engineering Contribution

• Designed and delivered a 10-service NestJS microservices system for the core product, with a separate Spring Boot payment service secured by Spring Security.
• Implemented tenant-aware marketing pages, frontend flows and backend APIs so each organization could operate as a branded product on shared infrastructure.
• Integrated PostgreSQL for relational workflows, MongoDB for document-oriented data, RabbitMQ for asynchronous processing and Docker-based CI/CD for repeatable delivery.
• Implemented multi-tenant SSL/domain handling and supported separate staging, QA and production environments.
• Owned backend architecture, service boundaries, payment workflows and production-readiness decisions across the platform.

System & Product Considerations

• Tenant isolation across marketing, frontend, backend and data layers
• A Spring Boot payment service inside a wider NestJS microservices architecture
• PostgreSQL and MongoDB used where each data model made sense
• RabbitMQ-backed asynchronous flows for operational work
• Multi-tenant SSL, staging, QA and production release discipline

Technical Areas

What This Project Taught Me

• Multi-tenancy has to be designed as a full product boundary, not only as a tenant_id column.
• A mixed stack can be a strength when service boundaries are clear: NestJS for product services, Spring Boot where payments and security needed stronger JVM discipline.
• Environment automation, SSL and CI/CD are not secondary work. They are what make a SaaS product trustworthy.