2026
EventFlow Microservices
An event platform split into independently deployable services for auth, events, tickets, and notifications, communicating over Kafka.

- Role
- Sole author
- Timeline
- May 2026
- Team
- Solo project
Overview
A multi-service event platform covering authentication, event lifecycle, ticketing, and notifications.
Challenge
An event platform needs auth, event lifecycle, ticketing, and notifications to evolve independently without a single deployable unit coupling them. Each domain must own its data, and cross-domain work must not require a synchronous call graph through every service.
Responsibilities
- Built the API gateway and its routing to each domain service.
- Implemented JWT authentication with registration and login.
- Implemented the event, ticket, and notification services with their DTOs, schemas, and Kafka topics.
- Wired Docker Compose for the local multi-service stack.
Solution
Put each domain behind its own service with a single gateway in front, and move cross-domain work onto an event bus instead of direct service-to-service calls.
Architecture
NestJS services (API gateway, auth, events, tickets, notifications) communicating over Kafka (kafkajs), PostgreSQL accessed through Drizzle ORM, JWT and bcrypt for authentication, Jest/Supertest for tests, Docker for local orchestration.
Technical decisions and trade-offs
- Chose Kafka as the transport for cross-service events so a service can be redeployed without the others being online, at the cost of eventual consistency and more moving parts locally.
- Kept a single API gateway as the only public entry point so clients never address individual services, which adds a hop but centralizes auth and routing.
- Used Drizzle ORM instead of TypeORM for typed SQL close to the schema, trading the richer decorator-based abstraction for explicit queries.
- Split the work service-by-service across commits so each boundary could be reviewed on its own.
Outcomes
- The repository runs as a documented local multi-service stack via Docker Compose with docker-compose.yml and Dockerfile present.
- Jest + Supertest test harness and end-to-end test entry points are present for the gateway and services.
Lessons learned
- Build output (dist/) ended up committed alongside sources; separating generated files from the reviewable diff would have made the service boundaries easier to read.
Technologies
- NestJS
- Kafka
- PostgreSQL
- Drizzle ORM
- Docker
- Jest
- Supertest

