Entity services are a microservices anti-pattern, writes Tareq Abedrabbo, independent software consultant. The core reason for this is that they form shallow modules, where the interface is complex in relation to the functionality it provides.

Entity services are modelled after defined entities (or nouns) within a system. For example, an accounts service, order service and customer service. Typically they have CRUD like interfaces which operate on top of these entities.

By taking this CRUD like approach, entity services tend to not contain any meaningful business functionality. Instead, they are shallow modules, not really offering any complex or useful abstractions. Thus, in order to achieve functional requirements, coupling between these services ends up being introduced:

Entity services are conceptually small but shallow. They do very little aside from manipulating or exposing their internal state. As such, they often have to be composed in order to be useful, so in that sense, they are not truly decoupled or independent.

When complex queries require access to multiple data sources, they fall outside the remit of entity services and are often implemented as separate services or views atop their own data.

A good abstraction allows unnecessary details to be minimised and hidden, thus simplifying the way we think about the system. Entity services do not give good value for money compared to the complexity they add.

Ultimately, these shallow entity services can turn into a cluster of highly coupled components, write Abedrabbo. This leads to an operational burden, where more components must be deployed, scaled and monitored. This high coupling can also lead to challenging release processes, where many microservices must be deployed in order to deliver a single piece of functionality.

It can also produce single points of failure, where many services depend on each other, meaning that if one fails it can bring down the entire system.

Abedrabbo also explains that entity services create conceptual complexity, as the knowledge of how to compose them is not immediately obvious. This is because service composition can occur anywhere in the system and is often not straightforward.

The pattern can also lead to easy to make breaking changes:

More subtly, entity services, and shallow services, in general, provide no meaningful mediation or indirection between the interfaces they expose and the functionality they implement. Thus, the client of the system become unwittingly coupled to the implementation details of its services, all the way down to the database. In such situations, it becomes very difficult for the service implementer to modify or optimise the system without breaking everything because of this lack of a buffer between interface and implementation.

Abedrabbo concludes that there is no single approach for decomposing a system into microservices optimally. However, he advises on some best practices. These include driving design from business requirements, hiding information effectively, and avoiding shared contexts between microservices. The decomposition should also avoid the creation of single points of failure, allow parts of the system to be scaled independently, and make it easy to implement new functionality by keeping it within a single microservice boundary.

I've seen a couple of these articles on InfoQ about Entity Services being an antipattern. Is there an author or community advocating for this approach? I feel like common wisdom already considers this level of service segregation to be fraught with issues.

I believe a lot of these discussions are happening based on experiences from the field. I've previously worked alongside both Andrew (InfoQ editor) and Tareq (author of the source piece) in a London-based consultancy, and we saw this anti-pattern quite a lot with clients.

I've also had quite a few chats with other consultants (from global consultancies) at conferences like QCon NY recently, who said the same thing. Although all of this is anecdotal, I believe that many engineers are mis-interpreting some of the core principles with microservices, DDD and service design. Hence the increase in the production of articles, and our corresponding coverage.

InfoQ Weekly Newsletter

Join a community of over 250 K senior developers by signing up for our newsletter. If you are based in the EEA, please contact us so we can provide you with the protections afforded to you under EEA protection laws.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our architect newsletter?

Subscribe to our industry email notices?

By subscribing to this email, we may send you content based on your previous topic interests. See our privacy notice for details.

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.