100k monthly active users can result in wildly different numbers of queries/requests/operations depending on what you're doing.
100k MAU for a static blog and 100k MAU for an online game simulating a real world economy will have vastly different usage patterns of the underlying databases/message queues/etc.
> With that in mind why spend so much resources on complexity where the only benefits are to the engineers that get to add another buzz word to their resume?
It's not the only benefits, it's making things potentially easier down the line; more often than not it can be premature optimisation (preparing for a future that never comes), but there are also plenty of examples of companies outgrowing their initial infrastructure and having to spend lots of time on rearchitecting everything. A lot of that time can be saved by thinking a little bit beforehand and making things theoretically scalable.
I really disagree on making things "easier," that's kinda my point. Forcing in solutions that work at Google or Facebook or Twitter into an experience that gets 0.01% of the traffic is bad engineering IMO.
This example of a 100k MAU was for a company that was 150+ years old. They know their customers, they know the business, they know the growth projections. The only people that didn't know this was the technology leadership team that was given a blank check to "modernize" while all it did was create a clusterfuck of services using technology that requires even more workers to maintain rather than going for pragmatic solutions.
I completely reject the notion that you think every project requires "thinking" as if workers there don't actually know what the business entails or what future growth projections were (hint, they haven't been changing much for nearly 70 years).
You don't need fancy bleeding edge solutions for 99% of businesses out there. You engineer for what you have, not what you want.
100k MAU for a static blog and 100k MAU for an online game simulating a real world economy will have vastly different usage patterns of the underlying databases/message queues/etc.
> With that in mind why spend so much resources on complexity where the only benefits are to the engineers that get to add another buzz word to their resume?
It's not the only benefits, it's making things potentially easier down the line; more often than not it can be premature optimisation (preparing for a future that never comes), but there are also plenty of examples of companies outgrowing their initial infrastructure and having to spend lots of time on rearchitecting everything. A lot of that time can be saved by thinking a little bit beforehand and making things theoretically scalable.