Series recap. Post 1 — Locking 101 for Serverless Devs covered the mental model: pessimistic vs optimistic locking, what each isolation level actually locks, and why short-lived functions amplify every locking pain point. Worth reading first — this post leans on it. In post 1, a thousand Lambdas queued on a single inventory row. That's the obvious failure mode — the kind you can almost see coming if you squint. Post 2 is about the one that actually wakes you up, because nothing in your dashboard says the word "lock": Lambda invocations: spiking, then flat-lining at the concurrency ceiling. Database CPU: 8%. Database connections: pinned at max. p99: timing out. Error rate: 100% on bookings, partial everywhere else. You restart the database. It works for ninety glorious seconds. Then it breaks again, the same way. That's a connection storm meeting an orphan lock. The lock is the actual cause. The connection storm is what turns it into a public incident with a postmortem doc attached.…