---
title: "Discussion on \"Observability and Scaling: Monitoring Event Lag and Handling Failure\" | Hashnode"
description: "Discussion on \"Observability and Scaling: Monitoring Event Lag and Handling Failure\". Day 7 of Building PulseCart: Event-Driven Architecture on GCP"
url: "https://hashnode.com/posts/observability-and-scaling-monitoring-event-lag-and-handling-failure/6a545971410abcfd6a71df3e"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Observability and Scaling: Monitoring Event Lag and Handling Failure](https://blog.madhav.dev/observability-and-scaling-monitoring-event-lag-and-handling-failure?utm_source=hashnode&utm_medium=feed)

Day 7 of Building PulseCart: Event-Driven Architecture on GCP

Jul 13 · 10 min read · blog.madhav.dev  
Read the article

-   [#gcp](https://hashnode.com/tag/gcp)
-   [#observability](https://hashnode.com/tag/observability)
-   [#event-driven-architecture](https://hashnode.com/tag/event-driven-architecture)
-   [#backend-engineering](https://hashnode.com/tag/backend-engineering)

## Written by

[Madhav Bhasin](https://hashnode.com/@madhavbhasin)

@madhavbhasin · Noida, India

  
[View profile](https://hashnode.com/@madhavbhasin)

Production patterns for backend engineers who are tired of hello-world tutorials.

Senior full-stack engineer and engineering lead with 5+ years building cloud-native systems at scale. I write about the things the docs don't cover — GCP, FastAPI, Terraform, event-driven architecture, and AI-powered backends. No hello-world demos.

## Responses 2

Markdown supported · ⌘↵ to post

[Jeongjin Shin](https://hashnode.com/@jeongjin0)

[Jul 13](https://hashnode.com/posts/observability-and-scaling-monitoring-event-lag-and-handling-failure/6a545971410abcfd6a71df3e/comment/6a54b332bd852da48e90832f)

The oldest\_unacked\_message\_age vs raw backlog distinction is the right one to lead with, most teams alert on the wrong metric early on. On the ordering-key hot spot problem at 10x, did you consider splitting the hot key onto its own subscription instead of sharding the whole topic? That way a bursty user doesn't stall throughput for everyone else sharing the same ordering key space.

[Madhav Bhasin](https://hashnode.com/@madhavbhasin)

[Jul 13](https://hashnode.com/posts/observability-and-scaling-monitoring-event-lag-and-handling-failure/6a545971410abcfd6a71df3e/comment/6a54b332bd852da48e90832f#reply-6a54b5543be3c54adb031c33)

Solid approach for predictable key spaces — isolates the blast radius without touching the whole topic. The catch is when the hot key is unpredictable (bots, sudden high-volume users) — you need tooling to detect and re-route dynamically, which is a different problem.

Relaxing ordering on non-critical event types is usually the safer default at scale. But your suggestion is the right first move before you get there.