CODEWITHSUNDEEP
architecturemicroservices
Inventor Andy
Inventor Andy

Reputation: 45

How do you orchestrate input validation when multiple services are involved?

I've been scratching my head at this one for a while now so I'd appreciate people's input.

Let's say I have a blog application with two services: blog and account. The blog service holds the blog info and any blog posts. The account service holds the user account info and what blogs they are assigned to.

The application needs a function that assigns an existing blog to a user. There's a function in the Account service called AddAccountToBlog.

To ensure that we don't create bad entries in either database, we need to check that the accountID and the blogID have corresponding records in the account and blog databases. We can do this with methods in each service such as AccountWithIDExists and BlogWithIDExists.

The question, then, is where do I call these methods?

Option 1 Create a connection to the blog service from the account service so the account service can remotely call BlogWithIDExists. It works, but it creates a dependency and tight coupling between the services.

Option 2 Add the remote calls to AccountWithIDExists and BlogWithID exists within the high-level service (RESTful API, GraphQL, whatever your favourite flavour is...) and handle the logic for checking this input. Again, it works, but it doesn't scale well. Let's say I have both a RESTful API and a GraphQL server, and maybe even divide the API into smaller API's or any other number of design choices. I have to remember to include that logic any time that functionality is implemented. There's also the risk of some cowboy coder bypassing the checks and making direct calls to the AddAccountToBlog method.

Option 3 Add an intermediary layer between the "public" endpoints (RESTful API, GraphQL) and the individual services. This contains the logic to call multiple services and validate the input. There's still a risk of Mr Cowboy Coder calling the AddAccountToBlog method directly but there's probably a way to lock down communications so that only calls from the intermediary layer can call the Blog and Account services. It's not foolproof, but it's easier to spot where the damage is being done. Also, this method does add another layer of complexity to the whole thing by introducing that go-between service.

Option 4 Hit me with your best ideas?

Upvotes: 1

Views: 320

Answers (1)

murtiko
murtiko

Reputation: 273

I think option #1 is not a bad choice to start with. I would be hesitant to call it a tight-coupling where services interact with each other through remote interfaces.

However there is a question: What should happen if a blog gets deleted? It may not be enough (depending on the use case) to validate the blog only during the "addAccountToBlog" operation. An alternative (but more complex and potentially costlier) option would be to implement some sort of synchronization mechanism between these services, e.g. use an event driven architecture where the account service subscribes to the (crud) events of the blog service and acts on them appropriately.

But i guess i would start with option #1 to keep things simple, if the deletion of blogs is not a problem.

Upvotes: 1

Related Questions