There is so much wrong with this I don't know where to even start. You want to "keep things simple" and not stand up a separate instance of MySQL/Postgres/Redis/MongoDB/whatever else. So, you:
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.
Yeah and good luck when the CEO starts asking for reports and metrics (or anything else that databases have been optimized over the last 50 years to do very well).
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.
I don’t want to go ad personam on the blog author - but checking his socials he is not really experienced person.
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.
Well that’s only 7y of working with people to learn from, it’s not nothing but it’s not enough credentials to make me go from “it’s a horrible idea” to “I must be missing something”
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.