If Week 1 was about onboarding, Week 2 was when things got real. I dove deep into what it means to build software you can monitor, trust, and scale. While I had some experience with tracing and metrics in theory, this was my first time actually weaving them into the core of a live FastAPI application — and the learning curve was steep but exciting.

Observability That Actually Matters

I’ve always heard that “you can’t improve what you don’t measure,” and this week proved that tenfold. Integrating Prometheus to collect real-time metrics like request latencies, active requests, and cache hits/misses gave me a firsthand look at what production monitoring looks like.

It wasn’t just about adding numbers — it was about:

Understanding what metrics actually matter
Making sure we’re not overloading the system while collecting them
Exposing data in ways that are useful for debugging and decision-making

Setting up Grafana dashboards and seeing them light up as traffic came in made the app feel alive. It felt empowering to watch the system from a bird’s-eye view and understand how each moving part performed.

OpenTelemetry: Connecting the Dots

OpenTelemetry took things even further. With tracing and structured logging in place, we could visualize how a single request flows across services. That level of visibility made me realize how crucial it is in any modern, microservice-aware system. It was a new tool for me, and I was genuinely impressed by its flexibility — and a bit overwhelmed by how much you can customize. I see why companies invest in observability early.

Stripe Integration: Bridging Backend and Billing

Implementing Stripe wasn’t too technically heavy this week, but it was an interesting shift — suddenly backend decisions weren’t just about performance, but about billing logic, security, and user trust. Seeing billing as part of the system architecture, not just a plug-in, gave me a better understanding of product-driven backend thinking.

Event-Driven with Apache Pulsar: My First Messaging System

Learning Apache Pulsar was one of the highlights of the week. It was my first exposure to a distributed messaging system, and it really opened my eyes to how decoupling parts of an application can make things not just faster, but more reliable and scalable. I implemented background publishers and consumers for user and auth events, and I was genuinely surprised how non-invasive it felt to build features around asynchronous flows.

What stood out to me about Pulsar:

The separation between producers and consumers
Its support for dead-letter queues and resilience
How it let us track sensitive flows like password resets in near real-time

Reflections

This week reshaped how I think about backend engineering. Before, I saw APIs and databases as the core. Now, observability, events, and infrastructure feel just as important. The tools weren’t just shiny new tech — they taught me to think like a systems engineer.

Week 2 at CyberOni: Observability and Events, Up Close