Design Naïvely
What exactly does it mean to avoid premature optimization when writing software?
When building a new town from scratch, don't plan for hi-rise buildings, complex freeway interchanges and underground mass transit lines. Start with the buildings and roads and parking lots that will attract people to your new town.
Which is worse?
- Spending 2x-3x the initial investment of time and money to demolish and rebuild infrastructure to support the town as it grows
- Spending 20x the minimal investment of time and money to build a city that could support a thriving community of thousands, but nobody shows up
Build just enough of your application to say you have the feature.
Do it the easy way.
Don't care that it won't work if you achieve Facebook-activity-level scale. That level of activity almost never shows up overnight.
Odds are good that you'll never need to.
And that's a good thing.
It freed you up to spend more time building more new ideas (naïvely). The more you build, the more likely one of those ideas is to find success.
So put it in the monolith. Use algorithms that are easy to implement. Avoid complex workflows like message queues and service busses.
Watch activity logs. Measure performance. When, and only when it's being stressed near to its breaking point so you have to closely monitor the feature during heavy usage periods to make sure it doesn't explode and ruin your day, and/or when those processes become critical-path to the success of your business, should you invest time and money to add complexity and support increased demand.
