Building an Enterprise Event-Driven DevOps Platform on Azure: Event-Driven Architecture, Data Services, and Observability (Part 2)

In the first part of this project, I built the foundation of a cloud platform.

Infrastructure was provisioned with Terraform. Microservices were deployed to Azure Kubernetes Service. CI pipelines built container images and pushed them to a registry. ArgoCD pulled those images into the cluster using GitOps.

At that point the platform could take code from a developer’s commit and run it inside Kubernetes automatically.

The system worked but it still behaved like a simple synchronous microservices application.

They evolve into event-driven systems, integrate managed cloud databases, and add deep observability so engineers can actually understand what the system is doing.

That is what this second phase of the project focused on.

The full platform code is available here:

https://github.com/jaeveloper/sre-proj-upgrade

The repository contains everything required to spin the platform up from scratch.

Infrastructure. Pipelines. Deployments. Telemetry. All of it.

The Architecture Starts to Look Like a Platform

The biggest shift in this phase was architectural.

Instead of services communicating only through synchronous calls, the system gained a messaging backbone.

The application flow now looks roughly like this:

Browser
   │
Frontend
   │
Core Microservices (gRPC)
   │
Checkout Service
   │
Azure Service Bus Topic
   │
KEDA Workers
   │
Payment / Email / Shipping

The checkout service no longer performs every action directly. Instead, it publishes an event when an order is placed.

Other services react to that event asynchronously.

This small change fundamentally alters how the system behaves.

Introducing the Event System

To make this work I integrated Azure Service Bus into the platform.

Rather than using a queue, the system uses a topic with multiple subscriptions. That allows different services to react to the same event independently without being tightly coupled.

Whenever a checkout completes, the application publishes an event to the topic. From there the event fans out to multiple worker services.

One worker handles payment processing. Another prepares shipping. Another sends email notifications.

Each service reacts to the same business event but processes it independently.

This pattern is extremely common in production systems because it decouples services and allows the system to grow without turning into a tangled web of synchronous dependencies.

Scaling Workers with KEDA

Once the event system was in place, the next question became how to scale the workers.

Running idle worker pods all the time would waste resources. The better approach is to scale them only when events exist, that is where KEDA comes in.

KEDA watches the Service Bus subscriptions and automatically adjusts the number of worker pods depending on the backlog of messages.

If the queue fills up, worker pods appear. When the queue empties, they disappear again.

The system effectively scales compute based on the actual workload being processed.

Watching this behavior in action for the first time was one of those satisfying platform moments where the pieces finally click together.

The Platform Gets a Data Layer

With asynchronous processing working, the next step was to move the application away from static data and give it real cloud-backed storage.

Two Azure services now power the platform’s data layer.

Cosmos DB stores the product catalog, while Redis handles shopping cart state.

Instead of loading product information from local files, the product catalog service now retrieves data directly from Cosmos DB. The database is automatically seeded during infrastructure provisioning, so the application always starts with a populated catalog.

Meanwhile the cart service uses Redis to store user cart state. Redis is ideal for this kind of fast-changing session-like data, providing extremely low latency while remaining horizontally scalable.

These additions move the system closer to how many real cloud applications are structured.

Observability: Seeing What the System Is Doing

As the system became more distributed, understanding what was happening inside it became much harder.

A single user request could now touch multiple services and trigger asynchronous background processing.

Without telemetry, debugging this would be nearly impossible.

To solve that problem I added a full observability pipeline built around OpenTelemetry.

Services emit traces and metrics. An OpenTelemetry Collector aggregates the telemetry. Prometheus gathers metrics. Grafana visualizes them. Azure Application Insights captures distributed traces.

Grafana dashboards provide a real-time view into how the system behaves: request latency, service activity, and resource usage across the cluster.

But the most interesting view appears in Application Insights.

There you can see a single request propagate through multiple services as a distributed trace.

A checkout request might pass through the frontend, the checkout service, the cart service, and the product catalog service before eventually triggering asynchronous worker processes.

Seeing the entire request path laid out visually makes debugging and performance analysis dramatically easier.

Watching the System Run

With the platform fully assembled, the user experience looks simple.

Items are added to the cart.

When checkout completes, the application publishes an event that triggers background workers responsible for payment processing, shipping preparation, and email notifications.

Behind the scenes, the system coordinates Kubernetes workloads, message queues, and cloud databases.

To the user it still feels like a simple web application.

That abstraction is exactly what a platform should provide.

GitOps Still Drives Everything

Despite the added complexity, the platform still follows the same GitOps workflow introduced earlier.

All infrastructure and application configuration lives inside the repository.

ArgoCD continuously reconciles the cluster state with what exists in Git. If anything drifts, the system corrects itself automatically.

The result is a platform that is reproducible, auditable, and easy to rebuild from scratch.

Where the Platform Ended Up

What started as a simple microservices deployment evolved into a small but realistic cloud platform.

It now includes event-driven processing, autoscaling workers, managed cloud databases, distributed tracing, metrics dashboards, and GitOps-driven deployments.

More importantly, the entire system can be recreated directly from the repository.

That was one of the core goals of the project.

Not just to deploy a working application, but to build something that resembles the architecture and operational patterns used in real production environments.

And along the way, solve the kinds of problems that inevitably appear when all those pieces start interacting.