Architecture questions go wrong when the answer depends on facts that were never given. "Should I use microservices?" has no answer. "Two developers, 300 customers, one slow report" has one.
Include these in your post:
- What the product does, in a line
- Scale today: users, requests, data size. Real numbers.
- Scale you actually expect in a year, as opposed to the scale you dream about
- Team: how many people touch the code, and how experienced they are
- Current setup: language, framework, database, hosting
- The problem: what hurts right now, with an example
- What you have considered, and what worries you about each option
- Constraints: budget, deadline, things you cannot change
When you answer:
- Say what you would do and what it would cost in time and complexity.
- Say at what size your answer changes.
- "It depends" is only an answer if you say what it depends on.
A useful default for this section: prefer the boring option that one person can keep running, and move off it when a measured problem forces you to.