If the simpler solution can handle your current and expected load, go ahead and ship it. Complexity should be a last resort, not a design preference.
When a system grows, there is a massive temptation to reach for something sophisticated - distributed queues, multi-region setups, complex caching layers. And sometimes, those are the right calls, but “sometimes”.
More often, the bottleneck is not the architecture - it is whether your team can reason about it at 2 am when things go wrong. Scaling a system also means “scaling” engineers - headcount, technical abilities, and keeping the system understandable.
Literally boring infrastructure with well-understood failure modes will almost always beat a fancy architecture. Every piece of complexity you add is a tax, and you almost always make your system fragile.
By the way, the best architecture is the one your whole team can debug without a runbook.