Hacker News Reader

Comment by jayd16 | Hacker News Reader

We jump through so many hoops to avoid this terrible pattern. This puts more load and less scaling options on your DB. If you need to upgrade how something is stored, you need to touch every service. And they didn't really solve their problem.

If you can't keep track of what services call each other, what makes you think you'll be able to keep track of who is writing out what data?

Reading how they did SOA (spaghetti of services with highly coupled interactions) I don't think putting that at the data layer is useful in the long run. They even suggest many services operating on the same data as a way to decorate the data as it haphazardly makes it way through this mess of an app. Their original problem was a poorly planned separation of concerns leading to cross service coupling. In DOA that still have it. Its just coupled directly through the datastore with no hope of cleaning it up without a massive migration.

View on HN

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.

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.

Hmm. I think it could work well. Thinking if Qt signals/slots mechanism but using database. If you have separate tables for publish subscribe (one writer multiple readers) it would be quick.

And to be honest, the services are loosely coupled between each other that is a great benefit. It’s not a “spaghetti of services” because a good design will carefully consider them.

Plus it could give some good benefits for auditing trails too and consistency in data storage/archiving.

>because a good design will carefully consider them.

I don't want patterns where I have to be good. Anything is possible if you're good but how does the pattern help and protect the developer?

That said, as a developer, how do I know some data should be owned by one service or another? Should I notify other services when I change data? Where is the separation of concerns? Is the DAL a monolithic codebase that knows who to notify or what event to write when things are updated?

I like event queues but instead of using something like ZeroMQ they seem to suggest using a custom rolled table. If I want to add a new event listener such that I have more than one, do I have to know that at event write time and write n messages? Do I store message completion separate from the message itself? Does the DAL handle that by knowing who needs what? Aren't we back to thinking about all those service interactions but in the DAL? So much work is glossed over that I can only assume the author hasn't worked with queues or an ESB very much.

The ultimate question though is, why are these services even separate if they're mutating the same data? Just merge the services (or at least the operation in question) instead of rewriting the entire app. Way easier than orchestrating all of your systems through a monolithic DAL.

> The ultimate question though is, why are these services even separate if they're mutating the same data? Just merge the services (or at least the operation in question) instead of rewriting the entire app.

Because if you did that you'd have a monolith, and microservices are really fashionable right now.

I am not sure if you are being serious or not.

Being fashionable is the worst possible reason for making technology choice, but sadly one which many developers mindlessly choose.

I agree with you, but I am being serious that there are developers stumbling into poor microservice architectures based on "microservices are best practice", ie. fashion.

Reply on news.ycombinator.com