How to manage this microservices dependency?

Question

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.

Answer 1

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.

Answer 2

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.