I have a bookshelf microservice that manages user books' status (pending, read, reading now...). It exposes some REST endpoints to set book status:

PUT /users/{userId}/bookshelf/pending/{bookId}
PUT /users/{userId}/bookshelf/read/{bookId}
PUT /users/{userId}/bookshelf/reading/{bookId}

This microservice stores no data about any book, just its identifier. My question is: what is the best way to check if book actually exists?

Now, I'm calling Book microservice (http call) to check it, but I'm afraid this may be a bottleneck in the future. I have been thinking in an event oriented solution (e.g. using a Saga) but I'm not sure how to architect it from a user point of view.

  • I'm not sure I understand the problem. The client shouldn't invent URIs, they get the URIs from somewhere (some other service). In what use-case can the client make an "invalid" call and why would that be of any interest to this service at all? Jul 6, 2021 at 10:39
  • The point is about data consitency which has somehow to be ensured by the process not the single service. Dec 14, 2021 at 10:33

2 Answers 2


Why does this service need to know whether a book exists? Would that change anything in its behavior (except rejecting requests for invalid book ids)?

If you define that service as just storing some status out of a finite list for arbitrary IDs (which may or may not be book ids) it could serve its purpose without introducing unnecessary coupling. For example, when you want to make sure that only valid ids can be used, you need to have a strategy for handling deletions or other events pertaining to book ids, which most likely makes the service more complicated and brittle without introducing much additional value.

  • Isn't a problem to store books status of books that doesn't exist? (arbitrary IDs) Isn't that corrupted data? When I ask user's pending books from the microservice, it will return non-existing book IDs.
    – Héctor
    Jul 6, 2021 at 11:33
  • If that is a hard requirement on this service, then you need to bite the bullet and add the book ID verification to the API. It will slightly slow down the API, and you might encounter the need for performance optimizations earlier, but that's the cost you pay for the given requirements. You may also consider the relative frequency of PUT operations versus GET operations returning lists of book IDs - it might be more efficient to filter out invalid IDs at that stage. Jul 6, 2021 at 15:50
  • @Héctor If the service is getting called, then isn't it the caller's problem, that he put a book which doesn't exist in the user's bookshelf? The caller should never do that, right? You are talking about adding an entire dependency just so you can assert that a programmer didn't make a mistake!
    – user253751
    Jul 9, 2021 at 16:26

Use Events to propagate the entity state changes around your services. If a book is created, fire a BookCreated event, if the book is deleted fire a BookDeleted event.. Listen for those events wherever you care about them and change your local data accordingly. That way you dont need the API call to do the check because your service will already know the answer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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