[lightlazer]

That is a great advice. However if scalability must be introduced later on, it can be really hard as there are many features that have been added to the monolith, and refactoring it to become scalable can be a huge task.

The conditions where the monolith must be converted to a scalable system should be defined as early as possible.

[dasil003]

Designing something to be “scalable” before it’s actually established is a recipe for premature optimization at best and a poorly baked SOA with service boundaries that make change incredibly difficult at worst.

It’s important to keep mind that SOA is about scaling teams first, code second and not really about throughout per se. A share-nothing web tier plus a couple judiciously applied databases and background job queues can effectively scale a huge proportion of applications without the overhead of a full SOA.

[herodoturtle]

This too is excellent advice.

Start off with a monolith if it makes most sense (in terms of simplicity / MVP) but from the start keep future scalability in mind and plan for it.

I like this.

[bovermyer]

Unless, of course, you intend to cap users at a specific amount for another reason.