2,147,483,647: the number that silently stopped every insert

transcript

2 AM. Your event log has gone quiet. No crash. No errors. Then you spot one number. 2,147,483,647.

It's the biggest number a 32-bit signed integer can hold. Your table logs about 4 million events a day. After 18 months, that's about 2 point 15 billion. Every possible ID, used.

A crashed database is loud. Reads fail. Everyone knows within minutes. An overflow is the opposite. Reads still work. Connections stay open. Metrics look stable. New records just don't arrive.

Every insert fails. So where did the errors go? Into a fire-and-forget writer that quietly swallows them. Meanwhile analytics, recommendations and revenue tracking are all broken. From one column type.

MySQL can't advance the counter. Inserts fail as duplicate keys. PostgreSQL says it plainly. Integer out of range. But here's the worst. An Oracle sequence set to cycle wraps around. It reissues old IDs. It doesn't fail. It lies.

So watch the ID space itself. At 50 percent used, plan the migration. At 70 percent, page on-call. At 90 percent, emergency response.

This was predictable from day one. With one line of arithmetic. Watch ID space like disk space. Monitor your math.

Full breakdown in the lecture.