We are about designing microservices application around REST API. The application is aimed to search, Create, Update and retrieve document from many heterogeneous repositories.

I'm wondering if I have to model the services around operations (each operation GET, PUT, POST, PATCH, ... as service) or around the repositories (each backend repository = service).


Microservice should be designed around the service they provide in the system.

So for example you might have a user service that's sole responsibility to is to store and authenticate users. All other services in your system then use this service to authenticate users.

And you might have a document storage service, that does nothing other than store a document (ie it doesn't also worry about user authentication, or converting the document to different formats per request)

I'm not quite sure what you mean by "model the services around operations", but if you mean you have a microservice for GET and a microservice for PUT, and each microservice has all the services to handled this task inside it, then no that would not be a good idea and sort of defeat the point

  • Thanks Cormac. Yes I want to identify the services for my Document Management project – Abdel Aug 20 '16 at 0:27

Both could work. It depends on how you want to define your resources. You could do gets/Posts of [The Document] from [The repository] and either offer to let your service find it or let the user specify an option in the URI, or you could Get/Post to each repository separately, and put it on the client to know or look up the correct repository for the document before calling to store/retrieve a document.

In terms of testability and re-use, More simpler resources is good, but on the other hand you do want as much of the logic to compose the simpler actions into more complex ones to be in the service space as you can to separate presentation from logic to decrease the amount you have to re-code for multiple presentation modes. This tends to make multiple layers of services, if your latency requirements allow it. Also, with finer grain services, you can do load balancing more easily, though watch out, the database or the network can be the silent bottleneck as with all distributed applications. Basically, there's a choice between splitting out common implementations into other web services and just using a common library which is not exposed as web services.


You should create services around the repositories , not about the operation as in operations case your business logic on a entity will be fragmented across various services which is not a good approach.

Also in repositories first define what exact business value your service provide then choose only those entities from the repository and define a service.

Learn more about microservices --- you could read from here

If you still have doubt ask more specific question by specifying the entities in a repository, will help :)


Thanks guys for your feedback. Yes either I'll create 4 services: one for get operation, another for put de (create document), another for delete and the 4th for update document (PATCH) well work. But also I can create 3 services each for specific repository and in this case each repository has own operation (GET, PUT, DELETE, PATCH). In other hand if I follow the best practice the design by business bounded context no one of the previous options is business context. May be is there are options I can't see?

Thanks again for answers,


  • One of the benefits of microservices is independent deployability and maintainability in the face of functional evolutions. Usually, when a feature evolves, all operations (GET, PUT, etc.) need to change, so I don't really see the point of dividing your microservices by operation. – guillaume31 Aug 23 '16 at 13:27
  • In any case, this kind of division is not the original intention of microservices. If you really only have one identified business context, better to have no microservices at all than microservices that will needlessly complicate your system. – guillaume31 Aug 23 '16 at 13:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.