If you're architecting an early-stage startup, this article covers almost nothing of worth.<p>The two most important architectural factors for early-stage startups are:<p>1. product velocity; eg, the ability to move fast, experiment, and try things out in prod.<p>2. resource modeling; eg, what are the core data models that your product will use and how do they relate to each other?<p>Everything else is noise until you hit P/M fit.<p>#2 is less important than #1, but it's the really the only design point that can make or break ease of scalability post-P/M fit.
I don't know what startups you work at, but in the early stage I'm focused on keeping costs down as far as possible and producing features as fast as possible; not spending time architecting something I can do once I have a team and enough capital to develop it.<p>A single frontend, single backend, a single DBMS, a single data analysis tool which can connect directly. I don't need a warehouse when I have 5k users.
Hoe many startups did you see with multi region databases?
Also, can you compare the approach to postgress + operators on kubernetes?
And how do you charge for cockrouch db?
You will inevitably rewrite everything right if you see good growth? This type of architecture stuff is surely over engineering mostly? Im not an engineer but have developed lots of web apps < 1000 users. Maybe outsource anything that requires this type of architecture, e.g. for satellite imagery processing GEE or Sentinel hub. Even then Sentinel Hub just serves from same region as where imagery presides. People are ok with that.
What other ways are companies accomplishing multi-region databases? It sounds like
they claim their approach is better/different than Active-Active replication.<p>@Cockroach Labs - Please consider adding your service to Azure too :)
The many functionalities that make up an application are often organised according to a common pattern. The pattern of the application is specified by this pattern.