The Problem with "Dumb" Connections
Think of a popular restaurant on a Friday night. Every customer who walks in demands that the head chef personally greet them, verify their identity, and escort them to their table before any cooking begins. With 10 customers, this is fine. With 10,000 customers arriving at once, the chef never cooks a single meal — they spend the entire night just saying hello. This is exactly what happens to a database during a Connection Storm.
In a standard application architecture, every time an application server needs to talk to the database, it opens a raw connection. That connection involves real, measurable work:
- TCP Handshake: A 3-way handshake (SYN → SYN-ACK → ACK) before a single byte of SQL is sent.
- TLS Negotiation (if encrypted): Certificate exchange, cipher negotiation — several more round trips.
- Authentication: The database verifies credentials, checks permission tables, and allocates a session context.
- Memory Allocation: Each open connection consumes RAM on the database server — typically 2–10 MB per connection for PostgreSQL, and 1–4 MB for MySQL, depending on buffer settings.
If you have a traffic spike — a flash sale, a viral post, a DDoS — and 10,000 application threads try to connect simultaneously, your database will spend 100% of its CPU just performing authentication handshakes. Zero CPU remains for actually executing queries. The database grinds to a halt. This is a Connection Storm, and it is one of the most common causes of database outages in production systems.
The insidious part is that the application code is doing nothing wrong. Each individual connection attempt is perfectly valid. The problem is the aggregate behavior at scale — a property that only becomes visible under load.