Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Microservices are an organizational technology. They allow small teams to work independently from other teams.

The most frequent problem that I see is that people design Microservices that are "small as possible" instead of "Small enough than a small team can own them". For example, I have seen teams of 5-7 developers owning 20 microservices which is crazy IMHO. I blame the pre-fix micro which is highly miss leading. Now, if you merge together these 20 tiny microservices doesn't make monolith. A monolith would be a service or application that is owned by multiple/many teams.

The other important aspect is that microservices should be loosely coupled and what I see is highly coupled microservices. How do you know you have highly coupled microservices? I have seen a few things.

- They share business logic and developers end up creating libraries with business logic which is very problematic.

- They share access to the tables.

- Changes in one often require changes in other microservices.

- Integration and unit tests are not enough. You need E2E tests, but these are hard to write and brittle.



Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: