Most bad designs are confident answers to questions nobody asked out loud.
What is this for. Who uses it, how often, and what actually happens if it's unavailable for an hour. Whether it's read-heavy or write-heavy, because that single answer changes everything downstream.
What must never be wrong. Which data has to be correct the instant it's read, and which can lag. What we can afford to lose in a crash — nothing, a second, an hour. These are business answers, and engineers guess at them far more often than they ask.
What happens when it breaks. The blast radius of each component. Whether a dependency being down means we fail, queue, or degrade. Whether every operation can be safely retried.
What are we accepting. Cost per request. The hardest thing here to change later. Who maintains this at 3am.
None of these are about technology. Answer them and the technology mostly picks itself. Skip them and the diagram becomes an argument about tools, where the strongest preference wins and nobody can say afterwards what was traded away.
A design is only as good as the constraints it was forced to answer to.