Madhav Bhasin

Three that actually hurt us: Migrate and refactor separately. When something breaks mid-migration you won't know which change caused it. Move first, clean up after. Don't assume equivalent services behave the same. SQS and Pub/Sub are both "message queues." The delivery guarantees and retry behaviour are different enough to surprise you. Write a rollback plan per service, not just for the database. When a Cloud Run service had issues post-deploy, we were improvising. A one-page runbook per service removes the stress. Good rule of thumb: if a decision feels rushed mid-migration, it probably is.

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.

Thanks, glad it resonated! You're right that idempotency is exactly where Pub/Sub's at-least-once delivery bites people, so it's front and center in Day 2. I'm planning to cover deduplication keys on the consumer (carrying a stable event ID through the envelope and tracking processed IDs) alongside the dead-letter topic setup. Curious whether you've leaned more on broker-side dedup or handled it in the application layer — always interested in what's held up in production.