Home
Feed

Extend

Hashnode Pro
Hashnode for Agents

Resources

The foreword
Hashnode gql skill

Buildful - AI coding agent that delivers frontier-level results at a fraction of the cost Bug0 - The AI-native e2e QA regression testing Hackathons Changelog Brand @hashnode on X Hashnode on LinkedIn Support - hello+support@hashnode.com Code of Conduct Terms Privacy Sitemap

Search Hashnode

Search posts, tags, users, and pages

Feed/

Discussion

Observability and Scaling: Monitoring Event Lag and Handling Failure

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

Jul 13·10 min read·blog.madhav.devRead the article

#gcp
#observability
#event-driven-architecture

#backend-engineering

Written by

Madhav Bhasin

@madhavbhasin · Noida, India

View profile

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.

Responses2

Markdown supported · ⌘↵ to post

Jeongjin Shin

Jul 13

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

Jul 13

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.