Not every system needs to be clever
There is a certain kind of engineer who reaches for the most sophisticated tool available the moment a problem appears. Distributed queues for a job that runs once a day. Event sourcing for a CRUD app with three tables. Kubernetes for a service that handles forty requests a minute.
I have been that engineer. Most of us have.
The cost of complexity
Complexity has a carrying cost that compounds quietly. Every abstraction layer you add is a layer a new team member has to understand before they can ship anything. Every clever pattern is a pattern someone has to debug at two in the morning when the alert fires.
Boring architecture — a plain relational database, a simple queue, a monolith with clear module boundaries — tends to be fast to reason about, easy to operate, and forgiving when things go wrong. It is rarely the bottleneck. The bottleneck is almost always something else.
Reliability is a design choice
The systems I have seen run best over five or ten years are not the ones built with the newest technology. They are the ones where the people who built them resisted the urge to show off. Where each component was chosen because it solved the problem in front of them, not the imagined problem three years away.
There is real craft in knowing when a simpler answer is the right answer. That restraint is harder than it looks.