Skip to content
Mina Samir
Back to projects

2026

EventFlow Microservices

An event-management application with separate authentication, events, tickets, and notification services. The gateway uses HTTP for request/response paths, Kafka carries lifecycle events, and the services currently share PostgreSQL storage.

EventFlow Microservices
Role
Sole author
Timeline
May 2026
Team
Solo project

Overview

Personal project: a multi-service event platform covering authentication, event lifecycle, ticketing, and notifications.

Challenge

Coordinate authentication, event lifecycle, ticketing, and notifications across separate services while making HTTP request paths, Kafka events, and shared PostgreSQL data dependencies explicit.

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. Request/response paths use HTTP through the gateway, while cross-domain lifecycle events are published over Kafka.

Architecture

NestJS services (API gateway, auth, events, tickets, notifications) that use HTTP for request/response paths and Kafka for lifecycle events, with PostgreSQL accessed through Drizzle ORM, JWT and bcrypt for authentication, Jest/Supertest for tests, and Docker for local orchestration. Services currently share one PostgreSQL database, so schema coupling and reliable event publication remain explicit design limitations.

Technical decisions and trade-offs

  • Chose Kafka as the transport for cross-service lifecycle events, accepting eventual consistency and more local moving parts in exchange for decoupled publishing.
  • Kept a single API gateway as the primary client entry point so callers do not address each service directly; the local Docker Compose stack still exposes individual service ports.
  • 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.yaml and Dockerfile present.
  • Jest + Supertest test harness and end-to-end test entry points are present for the gateway and services.

Lessons learned

  • Shared PostgreSQL storage couples service schemas; database writes and Kafka publication need a reliable consistency strategy before production use.

Technologies

  • NestJS
  • Kafka
  • PostgreSQL
  • Drizzle ORM
  • Docker
  • Jest
  • Supertest