|
> 1. Design for 10x your current scale, not 1000x. I'd even say that the advice counts double for early stage startups. That is, at that scale, it should be design for 5x. You could spend years building a well architected, multi-tenanted, microserviced system, whose focus on sound engineering is actually distracting your team from building core solutions that address your clients' real problems now. Or, you could instead redirect that focus on first solving those immediate problems with simplistic, suboptimal, but valid engineering. An early stage solopreneur could literally just clone or copy/paste/configure their monolith in a new directory and spawn a new database every time they have a new client. They could literally do this for their first 20+ clients in their first year. When I say this, some people look at me in disbelief. Some of them, having yet to make their first sale. Instead, they're working on solutions to counter the anticipated scalability issues they'll have in two years, when they finally start to sell and become a huge success. For another few, copy/paste/createdb seems like a stroke of genius. But I'm not a genius, I'm just oldish. Many companies did basically this 20 years ago and it worked fine. The reason it's not even considered anymore seems to be a cultural amnesia/insanity that's made certain practices arcane, if not taboo altogether. So we tend to spontaneously reach for the nuclear reactor, when a few pieces of coal would suffice to fuel our current momentum. |
I've seen this work great for multitenancy, with sqlite (again, a single beefy server goes a long way). At some point though, you hit niche scaling issues and that's how you end up with, e.g., arcane sqlite hacks. Hopefully these mostly come from people who have found early success, or looked at by others who want reassurance that there is an escape hatch that doesn't involve rewriting everything for web scale.