One of my favorite examples of a software bug—not because I like it but because the problem was so simple and the consequences so potentially disastrous—is the 911 service outage on April 9, 2014. For six hours that day, 911 service was unavailable for 11 million people. Over 6,600 emergency calls could not reach dispatchers.
The cause was a size limit on an auto-incrementing database field. The FCC labelled the bug as "preventable" and the press happily repeated the line. I image a number of engineers lost their jobs that day.
Any software developer or database architect should feel uneasy by that. All database fields have size limits. If software does not impose limits then the hardware certainly has physical limitations. How many databases have we configured with schema defaults? Do we carefully consider how many rows we will need? For high-volume systems are we regularly checking that the integer keys are not nearing overflow? Do we oppose UUIDs because of practical nuisance when they might be a useful solution to a serious problem? Do we have alarms configured appropriately?
Those questions make me uneasy because I don't always like the answer I would give. But it is the responsibility of a serious software architect to consider outlier scenarios and protect users from harm. In a field where "architects" and "engineers" are not bound by the mechanical constraints of physics, we must take care to define and consider the boundaries of the world in which we will create because we cannot take them for granted.