Let's Go asynchronous
summary
Compares synchronous HTTP printing to asynchronous messaging, shows RabbitMQ + Watermill causing an OOM-retry loop where one bad message kills pods repeatedly, and a delivery-ack timeout that makes long jobs run multiple times. Implements a Postgres-backed queue (PGQ) instead of RabbitMQ, adds per-message retry counters and visibility so rotten messages can be identified and quarantined. Publishes benchmarks: ~10k publishes/sec parity, handles hundreds of thousands of messages/day for this use case, with consumer pull latency as the main bottleneck.
AI-written summary · about
chapters (9)
- 0:00Introduction and background
- 2:53From sync to async systems
- 7:47Synchronous vs asynchronous trade-offs
- 12:04Introducing message queues
- 23:18Pitfalls in async production
- 27:49Out of memory loops
- 30:15PGQ and custom solutions
- 35:56When to use async
- 37:02Q&A session
related talks
01h 00mEvolutionary history of the RabbitMQ .NET Client towards concurrency
25mWhen the “Go”ing Gets Tough: Relieving Pressure on a Budget
30mHigh Performance Systems in Go
54mComplex Concurrency Patterns with Go
04mHandling slow requests in your Go web server
28mGopher in an Event-Driven playground
57mReliability Nirvana
01h 27mFlash Talks