Complicated systems can be satisfying to design because every box appears to solve a future problem. The difficulty is that each box also becomes a thing somebody has to understand, deploy, monitor, secure and recover. That cost arrives whether the predicted future turns up or not.
I prefer to begin with the smallest design that can carry the real workload in front of it. For a modest service that may be one application, one database, one deployment path and one documented restore process. None of those choices prevent later growth. They simply avoid paying for boundaries before there is evidence that the boundaries are useful.
Design for the bad day
The architecture that looks elegant during a planning session can feel very different when something has failed, the original author is unavailable and the documentation is a little out of date. On that day, ordinary tools and an obvious data flow are strengths. A person should be able to work out what happened, where the evidence lives and how to return the system to a known state without reconstructing six months of decisions.
Simple does not mean careless. A small system still needs useful logs, backups that can be restored, clear ownership and enough separation to stop one failure becoming every failure. The distinction is that each piece exists because it solves a known problem rather than because it makes the diagram look more mature.
Complexity is easiest to accept when it arrives with evidence. Split a service when load, ownership or failure isolation requires it. Add a queue when work genuinely needs to be decoupled. Until then, the simpler system usually creates more room to learn and less work to keep alive.