Event-driven architecture on Azure with Azure Functions

I’m designing a microservices-based hotel reservation system, and I’ve decided to build it on an event-driven architecture (EDA). What I want is for services to react in real time to what happens in the system, for each piece to be easier to scale and maintain, and for new services to plug in without touching the existing ones.

This architecture is the foundation I’ll build the rest of the system on.

What event-driven architecture is

It’s a way of designing software around producing and consuming events. An event is something that happened, or a state change inside a microservice, such as “Room 101 has been reserved” or “Guest 123 has checked out”. Services publish these events and subscribe to the ones they care about, so they communicate asynchronously and can react as things happen.

The pieces I need

I’ve identified four components.

Domain events

Domain events represent meaningful changes inside a microservice’s domain and capture exactly what happened. With them, each service can react to a state change and update its own internal state.

For example, when a guest checks out, a “Guest Checkout” event is raised with the data the process needs: the guest’s ID, the room number and the checkout date.

Event handlers

Event handlers are services that subscribe to events and run a specific action when one arrives. For “Guest Checkout”, a handler might update the guest’s status in the database or send a confirmation email.

I’m going to use Azure Functions as handlers, to get better performance and spend less. Azure Functions lets me write serverless code triggered by events from different sources, such as Azure Storage Queue, Azure Event Grid or Azure IoT Hub. That means I can scale event processing with demand, pay only for the compute time I use, and spend my time on code instead of managing infrastructure.

Event bus

The event bus is the middleware that distributes events between services. It routes them to the right place, provides message queuing and error handling, and sits in the middle of the communication.

In the reservation system, the bus would take the “Guest Checkout” event and send it to the relevant Azure Functions: room management, billing and the loyalty program. Each service reacts on its own without affecting the others.

Event Sourcing

Event Sourcing is a pattern where you store the history of events for a domain concept. When a guest checks out, the “Guest Checkout” event would be stored along with its data (guest ID, room number and checkout date).

That history is useful for auditing, debugging and business reporting. By replaying the sequence of events you can analyze how the system behaved, spot anomalies or assess the impact of a change.

What the system gets out of it

With EDA on Azure and Azure Functions as event handlers, services react to changes straight away and users get faster responses. Since each service runs independently, the system copes better with traffic spikes.

The part I care about most is decoupling: a service no longer depends on another one being available, which lowers the risk of cascading failures and makes it easier to maintain or replace a single service. I can also add or remove services without touching the rest. And on cost, with Azure Functions I only pay for the compute time that’s actually used.

Diagram

This Mermaid diagram shows how events flow through the reservation system:

Events go out from the Hotel Reservation Service to the services that depend on it: Room Management, Billing and the Loyalty Program. The Event Bus is what routes them between services.

The Azure Functions participant represents the serverless code that these events trigger to do specific work, such as room management actions, billing actions or loyalty program updates.

Next steps

I’ll keep writing here about how development goes and the problems I run into along the way.

You can follow the project in my GitHub repository: GitHub repository

If you use other approaches to improve the architecture and maintainability of your microservices, I’d like to hear about them.