Define what might change
Growth is about more than user counts. New regulations, sales channels or teams can change requirements. Describe plausible scenarios before selecting a technical structure.
Separate responsibilities
Well-defined components contain the impact of change. Prefer explicit interfaces and clear data ownership. Microservices are not an automatic answer: a modular monolith may fit available resources better.
Document trade-offs
Record context, rejected options and consequences. Then measure response times, errors and deployment effort. Revisit architecture when constraints change rather than with every new trend.