Hacker News Reader

Personally I always prefer Microservices and some sort of CI pipeline over a classic Monolith. Yes, it's painful sometimes but when using some best practices (e.g. one DB per service) it works surprisingly well and can offer benefits that monoliths just can't. But I think it's fair to write Monoliths for new projects - many people do.

View on HN

I cannot possibly understand why you would do that.

You're dropping the ability to do trivial joins, trivial reporting, trivial SQL aggregates, over... what, exactly?

Generally I believe it's done for encapsulation between teams. That way, each team can own their code without any fear of another team being able to break anything provided they all work to their contracts.

If you can perform a join to get the data yourself, nothing is stopping anyone from circumventing your API that is intended for fetching the data or by making breaking changes to the single database that your code relies on.

But yes, trivial joins is effectively the trade off for this encapsulation and can mean other services have to collect their own versions of data from services which means you now have eventual consistency.

Reply on news.ycombinator.com