Simple is what people are already using. And beware 'good for startups' tech. If you're successful you'll have legacy 'bad for scale' tech.
I don’t think we have anything to discuss here. He seems just to want to do cool stuff and his drop of databases seems to be because he just doesn’t know a lot of stuff there is to know.
I applaud attempt and might be that his needs will be covered by what he is doing.
But for everyone else yes, pick boring technology if you want to do startup because technology shouldn’t be hard or something you worry about if you are making web applications.
I'm not sure what qualifies as experience if Meta/Google doesn't. ;)
Just working at Meta/Google doesn’t impress me much just like Shania Twain would sing.
Just FYI, you are (perhaps unintentionally) showing your lack of experience.
There are many thousands of brilliant engineers for every brilliant engineer who also is a author/speaker/publisher. These are very different skills.
Also, perhaps the author _is_ the next Martin Fowler? You never know...
I am also not claiming I have a way to run every other new software compan.
According to LinkedIn:
- Masters in CS from UPenn
- 1 year as SWE at Google
- 6 years as SWE at FB/Meta
- 6 years running his own company
When I hear "not really experienced," I think recent college grad, not someone with a Master's and 15 years of industry experience.
Surely this is a parody article of some sort?
We do use Preset for metrics and dashboards, and obviously Preset isn't going to talk to our in-memory database.
So we do have a separate MySQL database where we just push analytics data. (e.g. each time an event of interest happens.) We never read from this database, and the data is a schemaless JSON.
Preset then queries from this database for our metrics purposes.
1. Create your own in-memory database.
2. Make sure every transaction in this DB can be serialized and is simultaneously written to disk.
3. Use some orchestration platform to make all web servers aware of each other.
4. Synchronize transaction logs between your web servers (by implementing the Raft protocol) and update the in-memory DB.
5. Write some kind of conflict resolution algorithm, because there's no way to implement locking or enforce consistency/isolation in your DB.
6. Shard your web servers by tenant and write another load balancing layer to make sure that requests are getting to the server their data is on.
Simple indeed.