mek-bookings – Event-Driven Bookings Microservice

Problem / Context

The point of the project was to learn how independent services communicate asynchronously through events instead of direct tight coupling. The bookings service needed to persist booking data, publish booking events, react to external events from other services, and keep the frontend updated in real time.

Solution / Architecture

The bookings service stores data in PostgreSQL and publishes booking events to Kafka. Other services in the wider exercise react asynchronously. The service also consumes relevant external events and maps incoming changes back to booking state. An SSE endpoint pushes updates to connected frontend clients so the UI updates without manual refresh. The React + Vite + TypeScript frontend provides a practical UI for viewing and managing bookings.

How It Works – Architecture Flow

1. 1A user creates or updates a booking through the frontend or API
2. 2The Bookings API stores the data in PostgreSQL
3. 3The service publishes booking events to Kafka
4. 4Other services in the wider system react asynchronously
5. 5The bookings service also consumes relevant external events
6. 6Incoming changes are mapped back to booking state
7. 7The SSE stream pushes updates to connected frontend clients
8. 8The UI updates without needing manual refresh

Goals

• Learn event-driven service communication in practice
• Build and consume Kafka events across service boundaries
• Integrate a PostgreSQL-backed microservice with async event flows
• Create a real-time frontend with Server-Sent Events
• Understand cross-team contracts and async workflow design

Challenges

• Aligning event contracts across teams working on different services
• Configuring Kafka/Aiven connectivity and certificates
• Keeping frontend state in sync with SSE events
• Handling status mapping from external services
• Avoiding duplicate processing and keeping consumers robust

Key Technical Decisions

• Use Kafka for asynchronous service communication instead of synchronous REST calls
• Use PostgreSQL + EF Core for persistent booking data
• Use SSE instead of a heavier real-time solution for one-way server-to-client updates
• Keep a dedicated frontend for making state changes visible
• Structure the project as a realistic learning case rather than a perfect production system

Results / Impact

• A working bookings microservice with CRUD-oriented booking flow
• Published and consumed Kafka events across service boundaries
• Real-time UI updates through Server-Sent Events
• Practical experience with async service communication
• Hands-on collaboration across service boundaries and shared message contracts

What I Learned

This project taught me how event-driven systems differ fundamentally from request/response thinking. I learned why contracts between services matter — especially when multiple teams need to agree on event schemas without tight coupling. I also saw firsthand how real-time UI updates can be driven directly from backend events via SSE, and how distributed systems introduce debugging and state-consistency challenges that don't exist in monolithic setups.

What I Would Improve Next

• Strengthen idempotency and consumer reliability
• Add more observability around event handling
• Formalize contracts more clearly across services
• Improve local development setup for multi-service testing
• Extend automated tests around event flows and SSE behavior