Hacker News Reader

Comment by kasey_junk | Hacker News Reader

The simple answer to this question is that all mature data stores have extremely sophisticated tooling for multiple concurrent access. Namespacing, views, access rights, concurrency/locking, migrations, stored procedures, etc are all things you end up poorly implementing at the app layer that you get out of the box at the data layer.

Every rdbms left on the stage was built with the assumption that lots of disparate systems would be coordinating within them.

I’ve yet to see a SOA system with half the tooling to support this. That’s before you get into the performance advantages.

If you’ve done a bad job coupling your data tier it’s because you didn’t know/follow best practices we’ve had for at least 30 years. Don’t blame the architecture for that.

View on HN

Agreed with kasey_junk.

Also assuming you are sane and give every service/user/etc their own user account into the DB, your DB logging will easily show user X did action Y.

Databases these days scale very well. PostgreSQL, which is a great OSS database can scale very well out of the box on any single system, and the size of X86 boxes are getting pretty giant these days(not to mention other platforms). Plus there are loads of 3rd party, but well supported, options for scaling past a single instance.

There are other systems like FoundationDB, etc that scale well out of the box, but I'd argue most people don't actually need to scale that large, 99% of us will never get to Google size and one can get very far on a single DB instance. Especially for new projects, scaling should be near the bottom of your todo list, until it starts to hurt, and then the general answer is, just throw money at the problem, since if you are having scaling problems, you better not also be having money problems or you likely have larger problems than scaling your DB.

You can accomplish this with a monolith too though. The service part is doing no work. And a stateless monolith is even easier to scale than a database.

Monoliths certainly can reach their breaking point for other reasons. But they can take you very, very far too. Depending upon your exact use case, a stateless monolith, Postgresql, and something like Redis can handle millions of daily users.

It's been a while since I've had to do this, about 10 years. The breaking point for our use case was around 6 million daily users. I would imagine you can take it further today, but haven't had the need to so I don't really know.

I would say nowadays, from a scale-up perspective we've never had it better.

Multi-core CPUs are cheaper than ever, and terabytes of RAM are not uncommon.

The only problem is that to have an HA solution with these monster machines, you need at least 2 of them, and maybe a similarly sized test system.

>If you’ve done a bad job coupling your data tier it’s because you didn’t know/follow best practices we’ve had for at least 30 years. Don’t blame the architecture for that.

Well that's exactly my point. The author is saying this architecture will save them and it wasn't the architecture at all.

Reply on news.ycombinator.com